Fix module entry deallocation in MODULE_DecRefCount

[Eric Pouech]

Warren_Baird at cimmetry.com wrote:
> 
> 
> 
>>the fix doesn't seem the right one... could you post a -debugmsg
>>+file,+module of what really happens here
> 
> 
> The places I've seen it happen are in parts of a large and complicated program -
> I'll see if I can find a simple test case that repros the problem and post a
> trace here.
> 
> But I can give you more details on what I found happening...   After calling
> LoadLibrary("foo") there were two entries for library foo in the
> MODULE_modref_list.  When you unloaded the library the first entry found was
> removed, but the 2nd entry remained, but the memory behind it didn't exist any
> more.  If you tried to load the library again, the loading code would find the
> entry in the modref list and try to reuse it, and immediately segfault...  I
> seem to recall that the first entry had the correct path to the library, and the
> send entry had "C:\windows\system\foo.dll" or something like that...
> 
> Note that I've only observed this on a sparc/solaris system - it may be due to a
> pecularity of the way libs are loaded there...
> 
> If I can repro it with a simple enough case to generate a reasonably sized log,
> I'll post it here, hopefully tomorrow...
it may well be that wine gets mixed up when loading two libs from 
different paths (or has some other bug in library handling)
but, given what you describe, it seems to be that the real issue isn't 
in library unloading (where you patch applies) but in either:
- library loading (how come you end up with two libs with the same modname)
- or library lookup (may be your code does LoadLibrary("foo.dll"), 
LoadLibrary("mydir/foo.dll"), and GetModuleHandle doesn't return the 
correct one... (and the module handle returned is used further for 
freing the library)

that's why a full trace would be helpful there

A+

-- 
Eric Pouech