Opened 14 years ago
Closed 14 years ago
#35 closed defect (fixed)
Release build of AWT.DLL is wrong
| Reported by: | dmik | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Milestone: | Beta |
| Component: | general | Version: | |
| Severity: | Keywords: | ||
| Cc: |
Description
When attempting to start an AWT program with a production release build, AWT.DLL can't get loaded: DosLoadModule() returns error 87 for it (invalid parameter).
Change History (4)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
I had many guesses regarding that but a lot of experiments and thinking pushed me to a suspicion that relocation (fixup) of global data addresses is done wrongly for some reason when the DLL is loaded by OS/2.
It took just another several hours to find out that the guilty person is WLINK, the one patched by Knut (note that I didn't try the non-patched one to see if it's Knut's patches or not). Switching from WLINK to the VAC308 linker cured the problem. ALl test AWT/Swing applications that I tried work now.
I'm going to rebuild all Java with the VAC308 linker and see if it will work then.
comment:3 by , 14 years ago
Tests show that the VAC308 build works well. But ILINK from VAC308 can't actually link the debug build of JVM.DLL, crashes and hangs in DosExitList... Will try ILINK 5.0 from Mozilla guys...
Tried ILINK 5.0 with the debug build. It brings its own problems :( Now, it doesn't want to pick up operator delete[] from one of the .obj files being compiled but instead takes it from libc.lib... WLINK took the right one. Investigating.
comment:4 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fixed the delete[] problem. ILINK will be our main linker for Java from now on.
It turned out that AWT.DLL is corrupt: its static and global data ends up in a wrong memory location when the DLL is loaded. This memory location does not correspond to the original data segment at all and may actually be any memory region including the code segment of another DLL or even a free memory block. Such misalignment leads to a very early crash in _DLL_InitTerm() of AWT.DLL when it calls constructors of global/static C++ objects (which rely in that invalid global data segment) which in turn cause memory access violation.