acizmarik / sharpdetect Goto Github PK

This can cause issues with unresolvable types if compiled during startup

Once objects are promoted (i.e. heap is reconstructed) GetObject fails. A different instance can be returned for a given object

Right now at least the implementation on Windows is wasteful of memory

There is an unstable test

https://github.com/acizmarik/sharpdetect/actions/runs/4526529079/attempts/1

The collection was expected to contain a single element, but it contained 2 elements.
at SharpDetect.E2ETests.GarbageCollectionTests.GarbageCollectionTests_ObjectTracking(String testName, Int32 expectedLockAcquiresCount) in /home/runner/work/sharpdetect/sharpdetect/src/Tests/SharpDetect.E2ETests/GarbageCollectionTests.cs:line 162
at SharpDetect.E2ETests.GarbageCollectionTests.GarbageCollectionTests_ObjectTracking(String testName, Int32 expectedLockAcquiresCount) in /home/runner/work/sharpdetect/sharpdetect/src/Tests/SharpDetect.E2ETests/GarbageCollectionTests.cs:line 164
--- End of stack trace from previous location ---

Need to update CI agents to support .NET 7
See: https://github.com/acizmarik/sharpdetect/actions/runs/3509910309/jobs/5879327509

Originally posted by @acizmarik in #27 (comment)

Helper methods can not be resolved because they are not referenced. We should also check definitions and not only references

Signals must arrive almost immediately. Multiplexing them with regular notifications can cause delays (for example when expecting heartbeats)

• Choose services that should be usable by plugins
• Instantiate plugins using available services (i.e. remove the Initialize method)

It is not ideal that it needs to be placed next to CLI assembly

Right now when a big GC occurs, a very big message gets generated. This happens during runtime suspension so all other threads are waiting until GC finishes... However, framework can already process it partially. It is probably sufficient to split the message into multiple smaller ones.

This breaks the application as the scheduler for the given process was already unregistered and disposed

Some interesting methods:

• ThreadPool
  • ThreadPool::UnsafeQueueUserWorkItemInternal(object callBack, bool preferLocal)
  • ThreadPoolWorkQueue::Dequeue(ThreadPoolWorkQueueThreadLocals tl, ref bool missedSteal)

We need to monitor sharing threads

See https://github.com/spectreconsole/errata