On 07/25/2006, Rob Hatcherson wrote:
>> I've been trying to track this down with gdb, but haven't made much 
>> progress.  I put the cygwin1.dbg from the src distro into the /bin 
>> dir, which at least allowed some level of breakpoint setting, but so 
>> far none of the ones I've tried (dlopen, dll::init(), and a few 
>> others in that vicnity) have been hit.  I'm not too familiar with the 
>> cygwin source base, so I may be snooping around in the wrong spot.
Larry Hall responded:
> Have you tried putting break points in the DLL init routines for 
> A.dll, B.dll,
> or just plain main()?
Had already tried main().  Whatever is happening is upstream of there.

Regarding DLL init routines, I assume you mean any DllMain defined for 
those DLLs.  I didn't have a user-defined DllMain in either DLL.  
Defining one for each DLL had no apparent effect with 1.5.21-1.

At this point I removed the DllMain's, set gdb aside, and ran the app in 
the DependencyWalker tool.  Here's the tail end of its report, where the 
problems seem to start (the full report "dwout_withoutDllMain.txt", not 
too much longer than this, is attached):

<snip>
00:00:00.172: Loaded 
"c:\workareas\buildoutput-main\zedasoft\c++\windows_x86\zedasoft\lib\LIBZEDASOFTFOUNDATION.DLL" 
at address 0x10000000 by thread 1.  Successfully hooked module.
00:00:00.422: First chance exception 0xC0000005 (Access Violation) 
occurred in "c:\windows\system32\NTDLL.DLL" at address 0x7C91E183 by 
thread 1.
00:00:00.422: Unloaded "Unknown" at address 0x004D0000 by thread 1.
00:00:02.250: First chance exception 0xC0000005 (Access Violation) 
occurred in "c:\windows\system32\NTDLL.DLL" at address 0x7C964ED1 by 
thread 1.
00:00:02.250: Second chance exception 0xC0000005 (Access Violation) 
occurred in "c:\windows\system32\NTDLL.DLL" at address 0x7C964ED1 by 
thread 1.
00:00:02.250: Exited 
"c:\workareas\prj-main\zedasoft\c++\libs\main\test\util\STRINGTOKENIZERTEST.EXE" 
(process 0x7DC) with code -1073741819 (0xC0000005) by thread 1.


At first glance one might see the Access Violation and say that this 
must be the problem.  However, seemingly innocuous changes to the 
"foundation" DLL cause the problem to morph.  For example, the 
attachment "dwout_withDllMain.txt" is from an attempt with the DllMain's 
put back in, and this one shows some kind of rebasing problem with an 
Unknown exception.

All this might suggest that there's some kind of memory corruption issue 
in our code base, but I'm not sure the load is even getting that far.  
For example, I expected to see a report about my DllMain being called in 
the dwout_withDllMain.txt log file, but there's no such report.  Does 
anything in the DLL get called prior to DllMain (e.g. global 
constructors, etc)?


Dave Korn responded:
>   Are you using C++ string classes?  Would you like to try recompiling it all
> using the new experimental gcc-3.4.4-2 release?  It addresses at least one
> known problem with C++ vs. DLLs.
>
> http://cygwin.com/ml/cygwin-announce/2006-07/msg00021.html
There's some string stuff in there, so I could give this a whirl.  
Though... the guy across from me has a cygwin gcc/g++ installation that 
reports the same version as mine, except over a 1.5.18-1 cygwin DLL, and 
everything works as expected there.  Of course who knows what *that* 
means, but FWIW I've never seen this symptom with this particular code 
base at or prior to 1.5.18-1, going back several years.  I can't speak 
to releases in between 1.5.18-1 and 1.5.21-1, as we haven't updated in a 
while.


I will keep digging, and report if I learn anything useful.  Further 
ideas on how to catch this are welcome too :-).

Thanks for your input.

Rob