DLL Collisions
Dinesh Jindal -- djindal@objectres.com
Wednesday, June 26, 1996
Env: VC++ 4.1 (patch VC41A), NT 4.0 Beta2 (Build 1314)
Hello,
I am writing a pretty big application using MFC, openGL,
ObjectSpace STL and bunch of other third party libraries. All
libraries are build with the code generation option 'Multithread
DLL'. The release version of my application runs fine, the debug
version too runs fine when not using the debugger. But when trying
to run the application through debugger it crashes during the
initialization i.e. WITHOUT even entering into InitInstance().
It displays the silly message box "User breakpoint called from
code at 0x77f...."
Going back into the call stack shows that the crash was caused by
++pfbegin; statement of _initterm() function in
MSDEV\CRT\SRC\CRT0DAT.C
void __cdecl _initterm (_PVFV * pfbegin, _PVFV * pfend)
{
while ( pfbegin < pfend )
{
if ( *pfbegin != NULL )
(**pfbegin)();
++pfbegin;
}
}
>>>>>output window messages.
LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
LDR: Dll O4LOW.dll base 10000000 relocated due to collision with
C:\OSTORE\BIN\O4CLIEN1.dll
LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
LDR: Dll O4LOWNET.dll base 10000000 relocated due to collision with
C:\OSTORE\BIN\O4CLIEN1.dll
LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
LDR: Dll O4_COLL1.dll base 10000000 relocated due to collision with
C:\OSTORE\BIN\O4CLIEN1.dll
Loaded symbols for 'C:\WINNT40B\system32\ntdll.dll'
Loaded symbols for 'C:\WINNT40B\system32\kernel32.dll'
..
snip-snip....other DLLs loading messages.
..
Loaded symbols for 'C:\WINNT40B\system32\glu32.dll'
HEAP[Objres.exe]: Heap block at cae6d0 modified at cae68d past
requested size of ffffffb5
<<<<<<<<<<<<
Could anyone please help me with what the meaning of this
LDR:Warning .. is and what could be the probable cause of this
strange behavior in debugger.
-Dinesh Jindal
Mike Dickson -- mike@digimed.com
Monday, July 01, 1996
[Mini-digest: 2 responses]
We have a 'thread' running on the MFC Collision error message, but this does
not sound like it is related to your problem.
What the collision error means is that two DLL's are set to load into the
same address. ( The default for MFC DLL's is 0x10000000 )
Since we can't do this one DLL is move to a new location and 'remaped' hence
the performance loss. But the program should run fine. If you have the
ability to relink the DLL's that cause the problem you can just set the
output in the linker options to load to a different default address and the
problem is fixed. There is a list of some reserved load address from MS on
one of the MSDN CD's.
Michael Dickson
-----From: Niels Ull Jacobsen
The LDR warnings tell you that you should rebase some of your DLL's.=20
Read up on this in the MSDN article "Rabsing win32 DLLs - the whole story=
".
But this is not critical and not what is causing the error.
The error is due to some memory overwriting while initialisng the librari=
es.
According to the error message, something has allocated a block with a si=
ze of
0xfffffb5 - that's probably -75? Try setting some breakpoints in the heap
allocation routines to find out what's happening.
Niels Ull Jacobsen, Kr=FCger A/S (nuj@kruger.dk)
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger=20
group and should be taken as legally binding in every respect.=20
Pigs will grow wings and fly.
David Leininger Anson -- dla4@cornell.edu
Sunday, June 30, 1996
> I am writing a pretty big application using MFC, openGL,
> ObjectSpace STL and bunch of other third party libraries. All
[CHOMP]
> It displays the silly message box "User breakpoint called from
> code at 0x77f...."
[CHOMP]
> >>>>>output window messages.
>
> LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
> LDR: Dll O4LOW.dll base 10000000 relocated due to collision with
> C:\OSTORE\BIN\O4CLIEN1.dll
> LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
> LDR: Dll O4LOWNET.dll base 10000000 relocated due to collision with
> C:\OSTORE\BIN\O4CLIEN1.dll
> LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
> LDR: Dll O4_COLL1.dll base 10000000 relocated due to collision with
> C:\OSTORE\BIN\O4CLIEN1.dll
> Loaded symbols for 'C:\WINNT40B\system32\ntdll.dll'
> Loaded symbols for 'C:\WINNT40B\system32\kernel32.dll'
> ..
> snip-snip....other DLLs loading messages.
> ..
> Loaded symbols for 'C:\WINNT40B\system32\glu32.dll'
> HEAP[Objres.exe]: Heap block at cae6d0 modified at cae68d past
> requested size of ffffffb5
> Could anyone please help me with what the meaning of this
> LDR:Warning .. is and what could be the probable cause of this
> strange behavior in debugger.
A good reference on base addresses of DLLs and EXEs (which seems to be
causing your problems) is Richter's Advanced Windows (page 208-9).
VERY briefly, it seems that the DLLs in question all want to be loaded at
the memory address 0x10000000. According to Richter, this is the Visual
C++ default. While the loader SHOULD be able to dynamically relocate
things, it may be having trouble in this case. Richter gives a few hints
for getting around this if you can build the DLLs - check out /FIXED and
/BASE.
As to the "user breakpoint," I am not sure exactly what mechanism Win32
uses, but from 16-bit x86 assembler, I know that debuggers will usually
set a breakpoint by putting an INT 03 instruction in your code. Could a
similar problem be present?
Sorry I can't be of more help, but I hope the reference proves useful.
David Anson
dla4@cornell.edu
Brad Ek -- bradek@sprynet.com
Wednesday, July 10, 1996
> I am writing a pretty big application using MFC, openGL,=20
> ObjectSpace STL and bunch of other third party libraries. All=20
[CHOMP]
> It displays the silly message box "User breakpoint called from
> code at 0x77f...."
[CHOMP]
> >>>>>output window messages.
>=20
> LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
> LDR: Dll O4LOW.dll base 10000000 relocated due to collision with
> C:\OSTORE\BIN\O4CLIEN1.dll
> LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
> LDR: Dll O4LOWNET.dll base 10000000 relocated due to collision with
> C:\OSTORE\BIN\O4CLIEN1.dll
> LDR: WARNING ! MAJOR PERFORMANCE LOSS in Objres.exe
> LDR: Dll O4_COLL1.dll base 10000000 relocated due to collision with
> C:\OSTORE\BIN\O4CLIEN1.dll
> Loaded symbols for 'C:\WINNT40B\system32\ntdll.dll'
> Loaded symbols for 'C:\WINNT40B\system32\kernel32.dll'
> ..
> snip-snip....other DLLs loading messages.
> ..
> Loaded symbols for 'C:\WINNT40B\system32\glu32.dll'
> HEAP[Objres.exe]: Heap block at cae6d0 modified at cae68d past
> requested size of ffffffb5
> Could anyone please help me with what the meaning of this
> LDR:Warning .. is and what could be the probable cause of this
> strange behavior in debugger.
A good reference on base addresses of DLLs and EXEs (which seems to be
causing your problems) is Richter's Advanced Windows (page 208-9).
VERY briefly, it seems that the DLLs in question all want to be loaded =
at
the memory address 0x10000000. According to Richter, this is the Visual
C++ default. While the loader SHOULD be able to dynamically relocate
things, it may be having trouble in this case. Richter gives a few =
hints
for getting around this if you can build the DLLs - check out /FIXED and
/BASE.
As to the "user breakpoint," I am not sure exactly what mechanism Win32
uses, but from 16-bit x86 assembler, I know that debuggers will usually
set a breakpoint by putting an INT 03 instruction in your code. Could a
similar problem be present?
Sorry I can't be of more help, but I hope the reference proves useful.
David Anson
dla4@cornell.edu
-----------
David's right. The "major performance loss" messages are caused by all =
your DLLs wanting to load at the same address. When this happens, the =
loader has to relocate all the addresses in your DLL, which adds extra =
time to the load process. This was happening with NT 3.51 too, it's just =
that the loader wasn't dumping the warning messages. The easiest way I =
found to resolve this was to use the editbin utility. This will take an =
EXE and as many DLLs as you want and compute a unique base address for =
each DLL so they all load cleanly without fixups. In the case shown, =
you'd do something like "editbin /rebase objres.exe o4low.dll o4net.dll =
o4clien1.dll" etc..... at the end of your build process. I'd probably =
just add this to my release build. It really does not matter much for =
debug builds. BTW, you should not rebase system DLLs, mfc40.dll, =
msvc40rt.dll, etc.
As for the int 3, one of the libraries you're using probably has a hard =
coded int 3 somewhere in it's startup code. I wouldn't worry about it.
Brad Ek
| Вернуться в корень Архива
|