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...
Warren
Warren_Baird@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 -
Warren_Baird＠cimmetry.com