This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Bug in cygcheck (1.7)
Christopher Faylor wrote:
> Have you investigated the possibility that one of the package files
> may be corrupted?
Not really -- but when I run cygcheck.exe under gdb, I get all the
packages listed properly (when 'set arg -cd') -- so I really don't think
that's it.
> Also, it seems like it's possible that the package
> list is not correctly set up. Have you tried dumping the addresses
> in a separate loop?
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 03:40:32 -0000
@@ -397,6 +397,13 @@
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)\t %s\n",
p, p->name, np, np->name, p->name);
+ fflush(stdout);
+ }
+ for (int i = 0; packages[i].name; i++)
+ {
if (check_files)
printf ("%-*s %-*s%s\n", package_len, packages[i].name,
version_len, packages[i].ver,
$ cygcheck -cd
Cygwin Package Information
Package Version
curr = 003E5590 (&name=003E9D30), next = 003E5598 (&name=003E6A30)
_update-info-dir
curr = 003E5598 (&name=003E6A30), next = 003E55A0 (&name=003E6A58)
aalib
curr = 003E55A0 (&name=003E6A58), next = 003E55A8 (&name=003E6A88)
aalib-devel
curr = 003E55A8 (&name=003E6A88), next = 003E55B0 (&name=003E6AB8)
alternatives
curr = 003E55B0 (&name=003E6AB8), next = 003E55B8 (&name=003E6AE0)
ascii-doc
curr = 003E55B8 (&name=003E6AE0), next = 003E55C0 (&name=003E6B08) ash
curr = 003E55C0 (&name=003E6B08), next = 003E55C8 (&name=003E6B30) atk
curr = 003E55C8 (&name=003E6B30), next = 003E55D0 (&name=003E6B58)
autoconf
curr = 003E55C8 (&name=003E6B30), next = 003E55D0 (&name=003E6B58)
autoconf
<<<< ... end of output ... >>>>
other runs are similar, but termination point differs.
> Given that cygwin1.dll is just barely initialized for use in cygcheck, I
> would not expect it to behave at all reliably under strace.
Oh, ok.
> Probably running it under strace causes a debugging thread to start
> which the cygwin DLL tries to handle. It's not going to be able to
> handle it though since it isn't fully initialized.
That makes sense.
> I really would not go down the strace road.
OK.
> Can you put an initial sleep in main() and then attach to the process
> using gdb? Sometimes attaching to a process rather than starting it
> directly makes a difference.
Okay, I did this. the first time, the fault was not triggered (the
entire package list was printed). The second time, the fault occurred.
Unfortunately, it appears the stack was clobbered. Picture/1000 words:
see attached.
...off to bed.
--
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/