billc@mirror.TMC.COM (Bill Callahan) (11/15/88)
Here's problem that we've been having, and I was wondering if anyone else has encountered it. We have a rather large application, with many DLL's (Dynamically Linked Libraries.) We discovered that we were crashing upon exit once our program began to get reasonably large and complex. Through our own experimentation and consultation with MicroSoft, we found out that the problem is with the loader and how it handles library locking. Below, I've quoted a response we got from MicroSoft on the nature of the bug and a workaround. Does anyone out there have some other ideas? ====================================================================== ====================================================================== The following is the response from the Windows developers explaining the problem with many DLLs in Windows. The problem is that the lock count value for each DLL is stored in a WORD and when the lock count goes over 32k, Windows crashes when it tries to unlock the DLLs when the app is exitted. As is described below, the ONLY solution is to decrease the number of DLLs that call other DLLs. -John Bartlow > Subject: problem with multiple dll links > Date: Thu Oct 20 14:59:30 1988 > > The problem with more than 23 DLLs linking to each other > has been found. What it amounts to is lock count overflow on DLL > segments caused by the locking algorithm whenever a DLL (or app > referencing a DLL) is loaded. You'd think that it would only be > incremented once each time it is another DLL or app which uses it > (directly or indirectly) is loaded. Instead, each direct > reference causes an increment, and each indirect reference > increments it, something like a depth 1st search on a tree (except > that the tree can have multiple cross references in the search > (maybe its a vine?)). Only circular references are prevented from > causing multiple increments. You can guess that this causes a > count overflow fairly rapidly. > > Of course the other side of the coin is that there is no work > around other than combining your DLLs. However, grouping your > DLLs much the same way that you would group source code into > segments will have an effect. For intance, have 7 DLLs which make > calls among themselves as much as they want, but allow only 1 of > those 7 to call a DLL outside the group. Yes, this bug will be fixed in > the next version of Windows. ============================== Well, there it is. Needless to say, combining libraries isn't always easy or fun. We'd like another choice. We could wait for the next version of Windows. It has also been suggested that we avoid the crash by terminating our program with a call to FatalExit rather than doing a normal exit. Again, any ideas? --------------------------------------------- Bill Callahan billc@mirror.TMC.COM {mit-eddie, pyramid, wjh12, xait, datacube}!mirror!billc