Message-ID: <44D115C1.9030004@zedasoft.com>
Date: Wed, 02 Aug 2006 16:14:41 -0500
From: Rob Hatcherson <rob DOT hatcherson AT zedasoft DOT com>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.21-1 DLL Loading Problem
References: <44C6B776 DOT 2080600 AT zedasoft DOT com> <44C6DCA2 DOT 1000709 AT cygwin DOT com> <44C7F4B8 DOT 50707 AT zedasoft DOT com>
In-Reply-To: <44C7F4B8.50707@zedasoft.com>
Content-Type: multipart/mixed;  boundary="------------010302070700000703050307"
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

--------------010302070700000703050307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------010302070700000703050307
Content-Type: application/x-tar;
 name="testcase1.tgz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="testcase1.tgz"

H4sIAObE0EQAA+1Z+2/aSBDm1+5fMSU5CRII+AGWSBOJJOTR43BEqNKeTrIW
ex3cGpuzTZQ+0r/9Zm2wzavcRYRIOX+KMDs7nhm8+83MOgHzA536TKjkng1V
hFKr8aug1KTwin+hfIKcUJXrsiCLklTPVQVRFOs5qD1fSAnGfkA9gJw3oIE+
YN4qvY7rsG3Es2UE8fq3XWr0cHSgj0ab9cEXuC7LK9dfUeqT9ZdkuS7i+uNF
zkF1s2Esx/98/XcsR7fHBoN3hm3qzsHgmCQiPzAsd0FkW/1Z2dixUMxlxHIC
GFLLKQD/Rr07vQT6AB/w3h4O7qFIvhNAGDbzPNcrFOEwHN+7lgF7A+rgBBzh
tDtiaCSPvr4xg/quGZju2DFoYLnOgWHb+RJ0e+0zraPewo/o60VbPWm2gZsM
bUaeOKIIQo+h8cR3rGKZBYgU3h5B50Mb7cRziSEOc+Thb0N1/M14Rwny53Fk
YCOJwKSWzYwG/Ob/5WCckdnpL52CPVhBQUhLH0n0SabxTB4HBlSdRJNEsjYK
ZoD6O/qPHU8MeywYew5aPCSPJM3/If3CTAx883tsHf9lRU7yv4ByQVLEjP9b
gWWyv6GwWzAtx/AD3FN3cPrp4vaqU9ot+ANm2zB26JAVi6VIHO1DtXfZ6mrt
s/N28+LmiDDbZ0vkZduwCXMMyyTk9OPHUAj7R1C+g/IttW1C8KNB3tzt78Nu
YapRBLX/melhHYIusxnuzmvXtcNx2Ucq49Yuu7AyNSwaTJc2fut0jEozERcJ
0dGf0wDyxhtC2TNhj1tMDLAHFg/IS6/dJpDwP3nqm/axjv+SIMb8r0oyr/+C
qGT83wbiKp5PU22QT8p7frIxUEZ4KvBHVGcwpR6WpESY8BDFBCtTozGko3dY
qEp9NHs8YXajoWnf/JsANfU/6AgrEW8WFueuUIolejoRXbFsf8dS9giPUKlA
7Nt/FWzcPhb4P9i8j5D/eMZbwX+kflT/JaWG/Of9v1RTpIz/28COZToGM0HT
/mydNW/U8552rn7onDV7V2pHU0/et0572iXZQR3LYevU1hwUogZj1eEhpffV
r4yoR4eL4uDriPmzYur7zAtmZXiUCezwRJLIMBWlVSwXw2F0OCsbUsdCtf+W
6cIzho1xTJLYXK+Orfo9DVgDe3We1mBJYpxPiKtu5YlyIUHGyuO+bekNiBPl
pPHnOov5kuyErRmXrlnVl96jGZ4PSf6fa7U36GNN/q9KVSXJ/wp//1cT5Cz/
bwUr+78n9Hr4JPUvPKkdp89t6Y7uhmvwdDQznxpE3d3M7M+F6az52xyW83+z
TeA6/tertYT/YpWf/2qYBjL+bwG/7v+6rXaredPSrlW1vbYLnFOe6fuQ9k9v
qlI78990Vqk0tCTzzDdLs9nlcGH+3vKCMbXh5zLFp7ZWc4/qBdc/4b83dp7J
R/g/nl+8/xHE+P2vUJX4+19RkcWM/9vAzttK33IqfeoPCGEPI9cLoH2mta9O
us3uJ+262bs8OmhwnUYFz3NTlQU5Oai8qveiGTJkyJAhQ4YMrxX/AAmrzdwA
KAAA


--------------010302070700000703050307
Content-Type: text/plain; charset=us-ascii

--
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/
--------------010302070700000703050307--