Another reason not to do anything scary in your DllMain: Inadvertent deadlock

re: Another reason not to do anything scary in your DllMain: Inadvertent deadlock

BTannenbaum — Wed, 28 Jan 2004 15:46:00 GMT

We've been bitten by this *many* times before.

The problem with the loader lock is that there's no documentation on which functions require it, so it jumps out and bites you when you're making an apparently innocent call. And to the best of my knowledge, there's no way for me to grab the loader lock in my code, so I could add it to my hierarchy.

And of course, this is all timing dependent, so it will work perfectly in the lab and hang randomly at a customer site.

re: Another reason not to do anything scary in your DllMain: Inadvertent deadlock

BTannenbaum — Wed, 28 Jan 2004 22:57:00 GMT

re: Another reason not to do anything scary in your DllMain: Inadvertent deadlock

keithmo — Wed, 28 Jan 2004 23:20:00 GMT

I hate it when my threads get all "pre-empty"... :-)

re: Another reason not to do anything scary in your DllMain: Inadvertent deadlock

Norman Diamond — Thu, 29 Jan 2004 01:07:00 GMT

To B. Tannenbaum: Since there's no way to know when you need the loader lock, the following is useless advice, but theoretically it would solve your deadlocks.

Define one more lock in your own design which serves no purpose by itself except to waste resources.

When you know that the loader lock is going to be grabbed by something you're going to call, lock your lock as just described. When you know that the thing you called is already finished with the loader lock, release your lock as just described.

Include your extra lock in your hierarchy.

Static object destructors?

Sven G. Ali — Thu, 29 Jan 2004 15:49:00 GMT

Don't static objects get destructed in DllMain? I think I ran into the loader lock when I had a static object whose job it was to manage a background thread. Its destructor set an event to break the thread out of its loop, then waited on the thread handle. A deadlock happened, and I think the reason was "resource inversion" between the loader lock and the thread handle. My quick "solution" was to bypass DLL_THREAD_DETACH by having the thread terminate itself instead of exiting cleanly. Could this be a valid use of TerminateThread?

re: Another reason not to do anything scary in your DllMain: Inadvertent deadlock

Mike Dimmick — Thu, 29 Jan 2004 16:58:00 GMT

Yes, static objects are destroyed in _DllMainCRTStartup, and yes, this can cause problems. I've been bitten by this, too.

Our solution was to remove any setup/teardown code from DllMain and provide InitLibrary/TermLibrary functions separately.

It can be quite frustrating to try to debug a process beyond the end of main().

re: Another reason not to do anything scary in your DllMain: Inadvertent deadlock

Raymond Chen — Fri, 30 Jan 2004 02:55:00 GMT

This ties into the comment from Norman Diamond on the other DllMain thread.

DllMain is a placeholder name for the actual DLL entry point you choose to use for your DLL. If you choose to use the C runtimes, then the entry point is really _DllMainCRTStartup. That function does some other stuff (like managing global destructors/constructors) and then calls a function called (confusingly coincidentally) DllMain.

In this case, then, the function you write called "DllMain" is NOT the actual DLL entry point, but an incredible simulation.

re: C scoped static initialization is not thread-safe, on purpose!

The Old New Thing — Tue, 09 Mar 2004 21:11:00 GMT

re: C scoped static initialization is not thread-safe, on purpose!

The Old New Thing — Tue, 09 Mar 2004 21:21:00 GMT

SimpleScript Part One: DllMain is Boring

Fabulous Adventures In Coding — Thu, 01 Apr 2004 09:02:00 GMT

SimpleScript Part One: DllMain is Boring

Fabulous Adventures In Coding — Thu, 01 Apr 2004 09:06:00 GMT

Things you shouldn't do, part 1 - DllMain is special

Larry Osterman's WebLog — Fri, 23 Apr 2004 19:36:00 GMT

Things you shouldn't do, part 1 - DllMain is special

Larry Osterman's WebLog — Fri, 23 Apr 2004 19:38:00 GMT

Why does windows hold the loader lock whilst calling DllMain?

/* Rambling comments... */ — Fri, 10 Sep 2004 00:54:00 GMT

I've been <a href="http://www.larkware.com/Articles/SomeSpelunkingHelp.html">splunking</a> around Dll loading recently for a pet project. It's been an interesting journey and this evening I solved the final piece of the puzzle and, when I did, I suddenly wondered, not for the first time, why Windows holds the <a href="http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx">loader</a> <a href="http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx">lock</a> when calling <code>DllMain()</code>...

Never, never ever call TerminateThread

Martin's WebLog — Sat, 06 Nov 2004 12:24:00 GMT

Sharing my thoughts… » Blog Archive » DllMain: Inadvertent deadlock

Sharing my thoughts… » Blog Archive » DllMain: Inadvertent deadlock — Tue, 27 Jun 2006 15:39:47 GMT

PingBack from http://sarathc.wordpress.com/2006/06/27/dllmain-inadvertent-deadlock/

Ice 'hangs' in destroy when called through DLL - ZeroC Forums

Ice 'hangs' in destroy when called through DLL - ZeroC Forums — Thu, 16 Oct 2008 16:17:41 GMT

PingBack from http://www.zeroc.com/forums/help-center/3991-ice-hangs-destroy-when-called-through-dll.html#post17578