Charles Wilson wrote:
> Christopher Faylor wrote:
>> I can't duplicate this either.
>
> Very strange. I'll see if I can't build a debug version of cygcheck and
> figure out what's going on.
It's very odd. It's intermittent, and I can't get it to occur under gdb.
Here's a bizarro for you. With the following patch
Index: dump_setup.cc
===================================================================
RCS file: /cvs/src/src/winsup/utils/dump_setup.cc,v
retrieving revision 1.18
diff -u -r1.18 dump_setup.cc
--- dump_setup.cc 19 Dec 2005 16:58:33 -0000 1.18
+++ dump_setup.cc 18 Aug 2008 01:45:58 -0000
@@ -397,6 +397,9 @@
check_files ? " Status" : "");
for (int i = 0; packages[i].name; i++)
{
+ pkgver* p = &(packages[i]);
+ pkgver* np = &(packages[i+1]);
+ printf("curr = %8p (&name=%8p), next = %8p (&name=%8p)\n", p,
p->name, np, np->name);
if (check_files)
printf ("%-*s %-*s%s\n", package_len, packages[i].name,
version_len, packages[i].ver,
I get the following output on successive runs:
$ cygcheck -cd
Cygwin Package Information
Package Version
curr = 003E5758 (&name=003E9F08), next = 003E5760 (&name=003E6BF8)
_update-info-dir 00749-1
curr = 003E5760 (&name=003E6BF8), next = 003E5768 (&name=003E6C20)
aalib 1.4rc5-2
curr = 003E5768 (&name=003E6C20), next = 003E5770 (&name=003E6C50)
aalib-devel 1.4rc5-2
curr = 003E5770 (&name=003E6C50), next = 003E5778 (&name=003E6C80)
curr = 003E5770 (&name=003E6C50), next = 003E5778 (&name=003E6C80)
$ cygcheck -cd
Cygwin Package Information
Package Version
curr = 003E5758 (&name=003E9F08), next = 003E5760 (&name=003E6BF8)
_update-info-dir 00749-1
curr = 003E5760 (&name=003E6BF8), next = 003E5768 (&name=003E6C20)
aalib 1.4rc5-2
curr = 003E5768 (&name=003E6C20), next = 003E5770 (&name=003E6C50)
curr = 003E5768 (&name=003E6C20), next = 003E5770 (&name=003E6C50)
$ cygcheck -cd
Cygwin Package Information
Package Version
curr = 003E5758 (&name=003E9F08), next = 003E5760 (&name=003E6BF8)
_update-info-dir 00749-1
curr = 003E5760 (&name=003E6BF8), next = 003E5768 (&name=003E6C20)
aalib 1.4rc5-2
aalib 1.4rc5-2
Note that the loop in dump_setup() is "on the last entry" when
next->name is null. That is never the case in any of the short runs
above. Also, in every case, the last line of output is doubled, and then
nothing further appears. The exit code in each case is 0.
Another odditiy: I know that cygcheck is not a cygwin program, but it
does load and iniitalize the cygwin dll. So, I ran it under strace. In
this scenario, sometimes cygcheck operates correctly, and sometimes it
does not. When cygcheck operates correctly, the strace log is
completely empty.
When it doesn't (that is, when I get a short output), the strace log
shows a single message:
--- Process 3872, exception C0000005 at 610031A8
The address is always the same (but addr2line reports '??:0' so that's
no help). In gdb, 'info line *0x610031A8' says
Line 59 of "/usr/src/kernel/src/winsup/cygwin/cygthread.cc" starts at
address 0x610031a8 <_ZN9cygthread4stubEPv> and ends at 0x610031ac
<_ZN9cygthread4stubEPv+4>.
54 /* Initial stub called by cygthread constructor. Performs initial
55 per-thread initialization and loops waiting for another thread
function
56 to execute. */
57 DWORD WINAPI
58 cygthread::stub (VOID *arg)
59 {
60 cygthread *info = (cygthread *) arg;
61 _my_tls._ctinfo = info;
62 if (info->arg == cygself)
63 {
Which doesn't tell /me/ much -- especially as the bad behavior never
occurs under gdb.
But, 0xC0000005 seems very familiar -- only, how can we have a "missing
dll" error, if the only dll involved is cygwin1.dll, and we're actually
executing code IN that dll when the exception occurs? In the mangled
words of Inigo Montoya, I do not think that exception means what you
think it means.
I /really/ wish that this behavior was observed by somebody else...sigh.
--
Chuck
--
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/
