1.5.21-1 DLL Loading Problem

Rob Hatcherson rob.hatcherson@zedasoft.com
Wed Aug 2 21:14:00 GMT 2006


All:

This is a follow-up to a couple of posts I made 7/25,7/26/2006 regarding 
DLL loading issues.  cygcheck output was attached to the first of my two 
posts.  The cause of the problem in its original incarnation is still 
undetermined, as it all seems to be happening upstream of main() where 
things are slightly harder to nail down.

I tried pushing the issue downstream of main() by loading one of the 
questionable DLLs directly via dlopen().  This also failed, so I pared 
it down to something small that still fails consistently (testcase1.tgz, 
attached).  While this isn't exactly the form of the problem I 
originally described, it's still DLL related, and the behavior is similar.

As indicated in my original post, this problem appears possibly related 
to previously reported DLL loading issues.  But... those are supposed to 
be fixed in 1.5.21-1.

I've run this app on two XP boxes and one Win2K box with the 1.5.21-1 
cygwin1.dll, and all failed with dlerror() reporting "permission 
denied".  FWIW on two of the machines I tried the 1.5.18-1 cygwin1.dll 
(same compiler version), and it always worked.

At first glance it would seem that "permission denied" is pointing to 
the issue, but simple (and irrational) changes to the source cause the 
problem to morph.  For example, commenting out the #include of 
ReleasePool.h in Object.cpp - which isn't strictly required in the test 
case Object.cpp but was a leftover from the paring down process - caused 
the failure to be reported as "bad address".  Commenting out other 
things, such as some of the static fields in the Object and/or 
ReleasePool classes, or the #include's in Object.h, permit dlopen() to 
load the DLL successfully.  Also, removing the -g from CXXFLAGS results 
in a build that works.  There are other variations.

At this point I'm looking for volunteers with the same cygwin/g++/etc... 
versions to try to build and run this, to see if the failure is 
consistent, or if we just happen to have a pile of confused machines at 
our office.  To run a) untar testcase1.tgz somewhere, b) make, c) 
./run.  It will either say the DLL loaded OK, or give a reason why it 
didn't.

Note that I have *not* yet tried gcc 3.4.4-2 as suggested earlier by 
Dave Korn.  I'll try to get to that shortly.  Have also not yet tried 
the current nightly build.

For any of you who have a moment to help, feel free to my private email 
if you prefer and I will be glad to summarize any findings in a future 
post to keep the chatter on the list down.

TIA for any help.

Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase1.tgz
Type: application/x-tar
Size: 1173 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060802/bd27ee8a/attachment.tar>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


More information about the Cygwin mailing list