0

I've got a base level function in xunit looks sort of like:

async Task LimitTestTo( Timespan maxTime, Task theTest )
{
    await Task.WaitAny( theTest, Task.Delay( timespan ));
    if (theTest.IsCompletedSuccessfully) return;
    // ?
    throw Exception(f"Test timed out after {maxTime}"});
}

And this works fine. However, it just tells me the thing failed - it doesn't tell me why. What I want is to use debugging sort of functionality where I have a ? to

  • if the other task is actually doing something
    • figure out what thread it's running on
    • pause that thread
    • get the stack trace
    • display it in the test output
    • terminate that thread
  • otherwise
    • explain why it's not - ie what it's waiting on or whatever

now obviously - cancellationtoken or anything can't work as a) I've got no knowledge of or control over the test passed in... b) it requires cooperation - by definition this will only ever occur in a time when a programmer has screwed up - it's probably waiting on a lock or something - so relying on the task to be nice and well behaved is pretty pointless.

I'm playing with dte.debugger.Localprocesses attach, but I'm hoping there's a way to do it from inside the app

bottom line - what I want to capture is why a test is hanging on the build machine... I couldn't care less if the rest of the program is now in a bad, unknown or corrupted state

Darren Oakey
  • 2,894
  • 3
  • 29
  • 55
  • So you're writing unit tests for timing multi-threaded functions and wanting to track down bottlenecks? Sort of sounds like https://github.com/mayerwin/vs-debug-single-thread could have half the code you're looking for. There's this silly but effective debugging hack where you randomly press pause / halt break and a good percentage of the time the code executing will be busy in the bottleneck. – Jeremy Thompson Jul 05 '22 at 06:28
  • no. not bottlenecks - performance has nothing to do with this - in fact I have a good profiling library for that. running tests and want to track down _problems_. - like occasionally the tests just hang (probably a deadlock). not my tests, and people are just running them again and they work - but I want the build system to be able to actually find the error. – Darren Oakey Jul 06 '22 at 01:16
  • So other peoples tests are failing and you want to report why they're hanging. Have you considered setting up DebugDiag to find out? It's a bit over kill but you're starting to get into the territory of 2nd chance exceptions, if the test is crashing, high cpu, OOM, hanging then often that's too late to get any diagnostic info. Ignore the Q&A but read the the comments to see what I mean https://stackoverflow.com/q/30326673/495455 – Jeremy Thompson Jul 06 '22 at 02:39
  • I just looked at debug diag - it looks like an IIS thing? Also I want this _inside_ the test framework and running all the time. Basically - it's almost certainly a deadlock - so I can almost guarantee that if I could capture the stackframes across all running threads - two of them would be sitting on a lock statement. I just want that. – Darren Oakey Jul 06 '22 at 05:26

0 Answers0