Weird threading problem? | Tech Off

spivonious

I've got a WPF app that does some major multi-threading in its worker classes. My problem is that as soon as all of the worker threads complete, the app shuts down. No errors, no exceptions, just shuts down the app and throws me back into the IDE.

After confirming that the threading is indeed working as intended with some debug.print statements, I am at a loss as to why this is happening.

Any ideas on further debugging steps?

The basic structure is this:

interface bound to "runner" object

runner holds collection of "sample" objects and spawns a thread for each sample

each sample holds as collection of "combinations" and spawns a thread for each combination

I'm using events to track when threads finish and then when everything is finished, I update the interface. Immediately after this step, the application shuts down.

spivonious

I took out all of the threading and the app runs fine on the same set of test samples. Grrr!!

Dexter

In reply to spivonious

#Oct 23rd @ 10:36 AM

How exactly are you sending the events from the worker thread to the user interface? In general you cannot call directly into the user interface from another thread than the one that created the user interface. You may need to pass the calls through the WPF Dispatcher.

figuerres
???

In reply to spivonious

#Oct 23rd @ 10:36 AM

almost sounds like the lackof workers is possibly creating a fault that sends an exit message to the gui thread....

or a fault on no workers is crashing the gui.

spivonious

In reply to Dexter

#Oct 23rd @ 2:15 PM

Yes, I actually have the events received by my main "runner" class, which then passes on any updates needed to the interface using the Dispatcher.

Figuerres - that was my thinking as well, but why would that be happening? I never send an exit message.

figuerres
???

In reply to spivonious

#Oct 23rd @ 5:07 PM

what happens if you create runner and the gui but nothing else?

does that crash / exit or not?

if it does then it's there

if not then one of the other threads is evil.

also do you have the .net source debug turned on ?

it might help in seeing where it's dying.

Dexter

In reply to spivonious

#Oct 23rd @ 5:07 PM

What happens when you run the application in the debugger? No exceptions?

spivonious

In reply to Dexter

#Oct 23rd @ 10:44 PM

Yep running in the debugger, no exceptions, just shuts down the debugger. Running outside of the debugger it brings down the whole app (this particular piece of code is a WPF control hosted in a WinForms control hosted in an ActiveX control hosted in a VB6 application). When debugging I'm running the WinForms control hosted in the User Control Test Container.

Dexter

In reply to spivonious

#Oct 24th @ 8:44 PM

Check the Output window of the IDE, maybe there's some debugger information in it (after the debugger exits). One cause for a process to exit without a trace is a stack overflow but normally you should see a StackOverflowException in the debugger if that happens. Hmm, maybe it's a stack overflow in an unmanaged thread, not sure how the managed debugger reacts to that...

spivonious

Okay, I turned on .NET source debugging and now I'm getting two exceptions.

The first seems to be unrelated, and just something in the test container:

First-chance exception at 0x7c812afb in UserControlTestContainer.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

If I click Continue the app runs for a while and then I get another exception. This is what brings the app down.

An unhandled exception of type 'System.Reflection.TargetParameterCountException' occurred in mscorlib.dll
Additional information: Parameter count mismatch.

Any ideas?

edit - just ran it again, didn't get the second exception, and the app still crashed. It seems to go down right before the WPF control would be shown. I wish I could run this in VS2010, but the Oracle Data Provider doesn't show up in the provider list, since MS changed how providers are listed in the registry.

edit2 - okay, I attached VS2010's debugger to the running app and caught the second exception above. It's got to be that.

edit3 - could it be something with the Dispatcher? It seems to get the error after everything processes but before the interface is updated. I basically made a subclass of ObservableCollection that holds a reference to the Dispatcher and performs a CheckAccess before each method call. If it has access it calls the base operation, if not it does a BeginInvoke for the method.

AndyC

In reply to spivonious

#Oct 26th @ 8:32 AM

Is this using the Thread Pool by any chance?

Classic race condition scenario if it is: you call CheckAccess whilst running on a thread and get true, before anything else happens the thread gets suspended, some time later the code starts again only this time on an entirely different thread pool thread (which would have got false from CheckAccess). Boom! Appcrash.

Solution: Always, always, use Invoke if you're using a thread pool.

spivonious

In reply to AndyC

#Oct 26th @ 9:20 AM

I'm not explicitly using thread pool. I just create a new System.Threading.Thread object for each thread I'm starting up.

I'll switch the BeginInvokes to Invokes and see if it helps.

edit: Nope, same result.

stevo_
Human after all

In reply to spivonious

#Oct 26th @ 9:33 AM

Not specifically related to the errors but spinning up threads 'on demand' for every task you want to run isn't really the best way to handle threading, because you have no context of how many threads you are spinning up for the entire app.

You would be much better abstracting your tasks so you can purely say 'here is some more work', and have a pool of workers (or something more advanced like the tpl) manage assigning threads to do work.

spivonious

In reply to stevo_

#Oct 26th @ 9:55 AM

It's not like that. I have a fixed collection of samples (although it's different depending the inputs to the program) and it makes one worker thread for each of those samples (and then each sample gets its own set of workers).

It's not one for "every task", it's one for every task that takes a while to run. Obviously I'm not going to see a huge benefit running on a dual-core, or even a quad-core CPU by splitting it up this much, but why limit the app to a predetermined number of worker threads? I'd trade some extra overhead for "future-proofing" anyday.

stevo_
Human after all

In reply to spivonious

#Oct 26th @ 10:30 AM

Thats not what an abstraction of tasks is (predetermined), its saying.. I don't care who does it, I want it done.

The TPL for example by default only spawns a single thread for each processor (so two for a dual core), and it considers them as delegates for a distinct actual processor.. it then enqueues work to them.

The idea is that in general purpose threading (ie not super tweaked custom arranged threading), the optimal amount of working threads is equal to the amount of processing units you have.. and similar to how the story of .net programs actually in some cases being faster than native because the compiler has so much more context about what you are trying to do, allowing it to generate better native code.. the task story is the same.. the 'tasks manager' as an entity has a much better context of how to best schedule threads for your entire app.. of course, you can pick to do a lot of work and manually manage threads for absolute performance, but the ROI in most cases is probably slim.

Blue Ink
C you

In reply to spivonious

#Oct 26th @ 8:32 AM

I don't know if that's your case, but you will get a System.Reflection.TargetParameterCountException if you call Dispatcher.Invoke passing the wrong number of arguments for the delegate.

Personally, I use lambdas. This way I can get the compiler to check the parameters and intellisense.

exoteric
I : Next<I>

In reply to stevo_

#Oct 26th @ 12:23 PM

The Parallel Extensions for .Net ("Px") is really nice this way, where you decide work resolution and Px decides optimal thread count based on hardware. So you can be quite aggressive on creating many tasks and expect to scale without unnecessary thread overhead - just some extra object creation overhead.

spivonious

In reply to Blue Ink

#Oct 26th @ 12:49 PM

I took another look at my calls to Dispatcher.Invoke and found something strange.

Intellisense tells me "delegate, priority, args".

My code was "priority, delegate, args" because that's how Bea Stolnitz's blog had it.

Changed it around and now I'm getting some other errors. Maybe that was it? Why would it even compile if the arguments were in the wrong order?

figuerres
???

In reply to spivonious

#Oct 26th @ 1:07 PM

I will guess that at some level both priority and delegate evaluate down to an int value.

seems like it would still complain in .Net but I can see how at the x86 level a number is a number. Smiley

Blue Ink
C you

In reply to spivonious

#Oct 26th @ 1:07 PM

Both versions exist (you may have noticed that if you hover on Invoke, you get a tooltip with "+9 overloads").

Yet, Intellisense only show four of them, as the other six have attributes that hide them ([Browsable(false), EditorBrowsable(EditorBrowsableState.Never)]).

It has been like that since .NET 2.0, so there must be some good reason for the hidden overloads, but I fail to see what that might be.

exoteric
I : Next<I>

Hi Spinovious, as we're both looking at threading and I was curious about the Thread.IsBackground (to set or not to set), I found this post which (on a quick skim) may be relevant to your exact problem

http://msmvps.com/blogs/jonathangreensted/archive/2005/02/16/36077.aspx

spivonious

Thanks Exo, I'll take a look at that.

My interface now starts to update, but I eventually get an "Object of type 'System.Object[]' cannot be converted to type 'System.String'" out of mscorlib. Since the only place I'm using an Object[] is in my Dispatcher.Invoke calls, it has to be something there. Why on earth would it be trying to convert it to a string?

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to spivonious

#Oct 27th @ 7:10 AM

As a guess, Dispatcher.Invoke uses params, so if you're manually passing in an object[], maybe you've got an errant parameter somewhere that is causing it to interpret the object[] as one of the parameters instead of the entire parameter list. It would be trying to convert it to a string if one of the parameters is a string.

Also, can't you break on the exception and check the call stack, would save a lot of guesswork.

Blue Ink
C you

In reply to spivonious

#Oct 27th @ 7:10 AM

Sorry if I'm missing something obvious... but why don't you use lambdas instead of passing arguments to Invoke?

Dispatcher.Invoke((Action) (() => MyMethod(argument1, argument2, argument3)), DispatcherPriority.Whatever);

Never checked how it fares in terms of performance, but it feels much easier to me.

spivonious

I was still getting crashes every so often even stripping out all but one level of threading and using the BackgroundWorker component.

I finally narrowed it down to a sort method in my "runner" object. The view object was being modified by the runner thread and not the UI thread, so when WPF tried to update its binding, the app crashed from the cross-thread operation. Put in a call to Dispatcher.CheckAccess and the crash went away.

They really need to make WPF interfaces threadsafe.