Mail Archives: cygwin/2008/08/17/23:22:59
On Sun, Aug 17, 2008 at 10:58:26PM -0400, Charles Wilson wrote:
>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.
Have you investigated the possibility that one of the package files
may be corrupted? 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?
>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.
Given that cygwin1.dll is just barely initialized for use in cygcheck, I
would not expect it to behave at all reliably under strace.
>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.
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.
>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.
#define STATUS_ACCESS_VIOLATION ((DWORD )0xC0000005L)
I really would not go down the strace road.
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.
cgf
--
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/
- Raw text -