This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug in cygcheck (1.7)


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]