Re: Bug in cygcheck (1.7)
On Aug 18 12:41, Christopher Faylor wrote: On Mon, Aug 18, 2008 at 04:34:10PM +0200, Corinna Vinschen wrote: On Aug 18 10:11, Christopher Faylor wrote: On Mon, Aug 18, 2008 at 03:39:30PM +0200, Corinna Vinschen wrote: So it's the FreeLibrary call which triggers the problem. What I don't understand so far is, why it does. Does this have any effect? Unfortunately not, it doesn't even change the frequency in which it occurs. I can so far only fix the problem by avoiding to call FreeLibrary. Disabling the call to shared_destroy from dll_entry doesn't help either. Did you try commenting out the stuff in DLL_THREAD_DETACH too? Looking at the code, it *shouldn't* be an issue but if it was actually getting called there would be all sorts of repercussions. Yes, I did. It didn't change anything, as you suspected. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: Bug in cygcheck (1.7)
On Aug 19 00:45, Charles Wilson wrote: Christopher Faylor wrote: I'd like to reproduce this since this is all basically code that I wrote. Corinna and Chuck could you privately send me your installed.db's in private email? Maybe if I use those I'll be able to see the problem. Done. Done 2. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: Bug in cygcheck (1.7)
On Aug 18 00:20, Charles Wilson wrote:
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.
I can reproduce the problem 1 out of 3 or 4. I also added some
additional debug output for a start:
get_packages()
[...]
for (n = 0; fgets (buf, 4096, fp) n nlines;)
{
char *package = strtok (buf, );
printf ((%8ld) %-20s :: %-20s\n,
ftell (fp), package ?: NULL, argv[0]);
[...]
}
printf (finished\n);
And that's weird, when the problem occurs, ftell(fp) prints the
same offset into the file twice:
[...]
( 502) automake1.8 :: openssh
( 545) automake1.9 :: openssh
( 545) automake1.9 :: openssh
and then the next call to fgets() just pegs out.
The next test was not to call load_cygwin(). In this case, the problem
seems to disappear. I can't reproduce it in 100s of calls.
Next, I call LoadLibrary (cygwin1.dll) but none of the other
processing in load_cygwin(). Still no problem.
Next, enable the FreeLibrary call. Now the problem reappears.
So it's the FreeLibrary call which triggers the problem. What I don't
understand so far is, why it does.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/
Re: Bug in cygcheck (1.7)
On Mon, Aug 18, 2008 at 03:39:30PM +0200, Corinna Vinschen wrote:
So it's the FreeLibrary call which triggers the problem. What I don't
understand so far is, why it does.
Does this have any effect?
cgf
Index: cygcheck.cc
===
RCS file: /cvs/uberbaum/winsup/utils/cygcheck.cc,v
retrieving revision 1.103
diff -d -u -p -r1.103 cygcheck.cc
--- cygcheck.cc 17 Aug 2008 17:15:41 - 1.103
+++ cygcheck.cc 18 Aug 2008 14:11:15 -
@@ -2003,7 +2003,7 @@ void
nuke (char *ev)
{
int n = 1 + strchr (ev, '=') - ev;
- char *s = (char *) alloca (n + 1);
+ char *s = (char *) malloc (n + 1);
memcpy (s, ev, n);
s[n] = '\0';
putenv (s);
@@ -2051,7 +2051,7 @@ load_cygwin (int argc, char **argv)
}
for (char **ev = envp; *ev; ev++)
if (strncmp (*ev, PATH=, 5) != 0)
-putenv (*ev);
+ putenv (strdup (*ev));
if (path)
putenv (path);
}
--
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/
Re: Bug in cygcheck (1.7)
On Aug 18 10:11, Christopher Faylor wrote: On Mon, Aug 18, 2008 at 03:39:30PM +0200, Corinna Vinschen wrote: So it's the FreeLibrary call which triggers the problem. What I don't understand so far is, why it does. Does this have any effect? Unfortunately not, it doesn't even change the frequency in which it occurs. I can so far only fix the problem by avoiding to call FreeLibrary. Disabling the call to shared_destroy from dll_entry doesn't help either. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: Bug in cygcheck (1.7)
On Mon, Aug 18, 2008 at 04:34:10PM +0200, Corinna Vinschen wrote: On Aug 18 10:11, Christopher Faylor wrote: On Mon, Aug 18, 2008 at 03:39:30PM +0200, Corinna Vinschen wrote: So it's the FreeLibrary call which triggers the problem. What I don't understand so far is, why it does. Does this have any effect? Unfortunately not, it doesn't even change the frequency in which it occurs. I can so far only fix the problem by avoiding to call FreeLibrary. Disabling the call to shared_destroy from dll_entry doesn't help either. Did you try commenting out the stuff in DLL_THREAD_DETACH too? Looking at the code, it *shouldn't* be an issue but if it was actually getting called there would be all sorts of repercussions. 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/
Re: Bug in cygcheck (1.7)
On Mon, Aug 18, 2008 at 12:41:09PM -0400, Christopher Faylor wrote: On Mon, Aug 18, 2008 at 04:34:10PM +0200, Corinna Vinschen wrote: On Aug 18 10:11, Christopher Faylor wrote: On Mon, Aug 18, 2008 at 03:39:30PM +0200, Corinna Vinschen wrote: So it's the FreeLibrary call which triggers the problem. What I don't understand so far is, why it does. Does this have any effect? Unfortunately not, it doesn't even change the frequency in which it occurs. I can so far only fix the problem by avoiding to call FreeLibrary. Disabling the call to shared_destroy from dll_entry doesn't help either. Did you try commenting out the stuff in DLL_THREAD_DETACH too? Looking at the code, it *shouldn't* be an issue but if it was actually getting called there would be all sorts of repercussions. I'd like to reproduce this since this is all basically code that I wrote. Corinna and Chuck could you privately send me your installed.db's in private email? Maybe if I use those I'll be able to see the problem. 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/
Re: Bug in cygcheck (1.7)
Christopher Faylor wrote: I'd like to reproduce this since this is all basically code that I wrote. Corinna and Chuck could you privately send me your installed.db's in private email? Maybe if I use those I'll be able to see the problem. Done. -- 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/
Re: Bug in cygcheck (1.7)
Charles Wilson wrote: cygcheck seems really confused, on my 1.7 installation (which is XPsp3 on a VMware virtual image). Or I am. $ uname -a CYGWIN_NT-5.1 VMWARE-XP 1.7.0(0.186/5/3) 2008-08-15 15:17 i686 Cygwin $ cygcheck -cd Cygwin Package Information Package Version _update-info-dir00749-1 aalib 1.4rc5-2 aalib-devel 1.4rc5-2 aalib-devel 1.4rc5-2 ^ this is the actual end of the output. It gets truncated very early, and the last line gets duplicated. But, I have lots of packages installed: $ cat /etc/setup/installed.db INSTALLED.DB 2 aalib aalib-1.4rc5-2.tar.bz2 0 aalib-devel aalib-devel-1.4rc5-2.tar.bz2 0 alternatives alternatives-1.3.30c-2.tar.bz2 0 asciidoc asciidoc-8.2.7-1.tar.bz2 0 ash ash-20040127-4.tar.bz2 0 atk atk-1.10.3-1.tar.bz2 0 ... I manually snipped 200 or so lines right here ... xterm xterm-229-1.tar.bz2 0 zip zip-2.32-2.tar.bz2 0 zlib zlib-1.2.3-2.tar.bz2 0 _update-info-dir _update-info-dir-00749-1.tar.bz2 0 I believe the problem has *something* to do with output buffering, because the output is correct -- that is, the 'head' is what I expect -- except that it cuts off too early, and the tail goes into the bitbucket. Also, successive runs of the same cygcheck command don't all cut off at exactly the same line. Redirection makes no difference. I'm running these commands from a normal cygwin (bash in cmd) window, with CYGWIN='server'. I'd attach a 'cygcheck -s -v -r' output, but it's not very informative. It's cut off after 10 lines or so. -- Chuck [snip] Heh. I'm not able to reproduce this at all. I did it both from a standard command prompt and from a bash shell without issue. I'll attach output from my own system. $ uname -a CYGWIN_NT-5.1 Shinji-Winxp 1.7.0(0.186/5/3) 2008-08-15 15:17 i686 Cygwin -- Robert Pendell [EMAIL PROTECTED] A perfect world is one of chaos. Thawte Web of Trust Notary CAcert Assurer Cygwin Configuration Diagnostics Current System Time: Sun Aug 17 08:23:38 2008 Windows XP Media Center Edition Ver 5.1 Build 2600 Service Pack 3 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\cygwin\home\shinji\C C:\cygwin\Program Files\GNU\GnuPG\pub C:\Program Files\Support Tools\ F:\xampplite\mysql\bin C:\Program Files\QuickTime\QTSystem\ C:\Program Files\Nmap C:\cygwin\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 1006(shinji) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) 10545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1006(shinji) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) 10545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'shinji' PWD = '/home/shinji' HOME = '/home/shinji' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\shinji' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\shinji\Application Data' HOSTNAME = 'Shinji-Winxp' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel' WINDIR = 'C:\WINDOWS' OLDPWD = '/usr/bin' OPTWARE_TARGET = 'oleg' USERDOMAIN = 'SHINJI-WINXP' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' !:: = '::\' VS90COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\' TEMP = '/cygdrive/c/DOCUME~1/shinji/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' QTJAVA = 'C:\Program Files\Java\jre1.6.0_07\lib\ext\QTJava.zip' USERNAME = 'shinji' PROCESSOR_LEVEL = '6' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\shinji' ULTRAMON_LANGDIR = 'C:\Program Files\UltraMon\Resources\en' CLIENTNAME = 'Console' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\SHINJI-WINXP' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' OPENSSL_CONF = 'C:\OpenSSL\bin\openssl.cnf' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/shinji/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'Canon iP4300' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0f06' CLASSPATH = '.;C:\Program Files\Java\jre1.6.0_07\lib\ext\QTJava.zip' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' DISPLAY = 'localhost:0' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'SHINJI-WINXP' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
Re: Bug in cygcheck (1.7)
On Sun, Aug 17, 2008 at 08:24:46AM -0400, Robert Pendell wrote: Charles Wilson wrote: cygcheck seems really confused, on my 1.7 installation (which is XPsp3 on a VMware virtual image). Or I am. $ uname -a CYGWIN_NT-5.1 VMWARE-XP 1.7.0(0.186/5/3) 2008-08-15 15:17 i686 Cygwin $ cygcheck -cd Cygwin Package Information Package Version _update-info-dir00749-1 aalib 1.4rc5-2 aalib-devel 1.4rc5-2 aalib-devel 1.4rc5-2 ^ this is the actual end of the output. It gets truncated very early, and the last line gets duplicated. Heh. I'm not able to reproduce this at all. I did it both from a standard command prompt and from a bash shell without issue. I'll attach output from my own system. $ uname -a CYGWIN_NT-5.1 Shinji-Winxp 1.7.0(0.186/5/3) 2008-08-15 15:17 i686 Cygwin I can't duplicate this either. FWIW, the Cygwin version shouldn't really matter since cygcheck is nearly a pure-windows program. 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/
Re: Bug in cygcheck (1.7)
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. FWIW, the Cygwin version shouldn't really matter since cygcheck is nearly a pure-windows program. True -- but it is the version of cygcheck that shipped with the cygwin-1.7.0-28 package, from the 2008-08-15 CVS. I don't know if there have been any relevant changes in the cygcheck source code, but if there have been, then the pedigree of my cygcheck.exe matters. -- 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/
Re: Bug in cygcheck (1.7)
On Sun, Aug 17, 2008 at 01:11:01PM -0400, 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. FWIW, the Cygwin version shouldn't really matter since cygcheck is nearly a pure-windows program. True -- but it is the version of cygcheck that shipped with the cygwin-1.7.0-28 package, from the 2008-08-15 CVS. cygcheck versions are really only loosely coupled to cygwin versions, though. cygcheck --version output would be slightly more useful when reporting cygcheck problems. 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/
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 - 1.18
+++ dump_setup.cc 18 Aug 2008 01:45:58 -
@@ -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-dir00749-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-dir00749-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-dir00749-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 C005 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 {
60cygthread *info = (cygthread *) arg;
61_my_tls._ctinfo = info;
62if (info-arg == cygself)
63 {
Which doesn't tell /me/ much -- especially as the bad behavior never
occurs under gdb.
But, 0xC005 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/
Re: Bug in cygcheck (1.7)
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 - 1.18
+++ dump_setup.cc 18 Aug 2008 01:45:58 -
@@ -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-dir00749-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-dir00749-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-dir00749-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 C005 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 {
60cygthread *info = (cygthread *) arg;
61_my_tls._ctinfo = info;
62if (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, 0xC005 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 )0xC005L)
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:
Bug in cygcheck (1.7)
cygcheck seems really confused, on my 1.7 installation (which is XPsp3 on a VMware virtual image). Or I am. $ uname -a CYGWIN_NT-5.1 VMWARE-XP 1.7.0(0.186/5/3) 2008-08-15 15:17 i686 Cygwin $ cygcheck -cd Cygwin Package Information Package Version _update-info-dir00749-1 aalib 1.4rc5-2 aalib-devel 1.4rc5-2 aalib-devel 1.4rc5-2 ^ this is the actual end of the output. It gets truncated very early, and the last line gets duplicated. But, I have lots of packages installed: $ cat /etc/setup/installed.db INSTALLED.DB 2 aalib aalib-1.4rc5-2.tar.bz2 0 aalib-devel aalib-devel-1.4rc5-2.tar.bz2 0 alternatives alternatives-1.3.30c-2.tar.bz2 0 asciidoc asciidoc-8.2.7-1.tar.bz2 0 ash ash-20040127-4.tar.bz2 0 atk atk-1.10.3-1.tar.bz2 0 ... I manually snipped 200 or so lines right here ... xterm xterm-229-1.tar.bz2 0 zip zip-2.32-2.tar.bz2 0 zlib zlib-1.2.3-2.tar.bz2 0 _update-info-dir _update-info-dir-00749-1.tar.bz2 0 I believe the problem has *something* to do with output buffering, because the output is correct -- that is, the 'head' is what I expect -- except that it cuts off too early, and the tail goes into the bitbucket. Also, successive runs of the same cygcheck command don't all cut off at exactly the same line. Redirection makes no difference. I'm running these commands from a normal cygwin (bash in cmd) window, with CYGWIN='server'. I'd attach a 'cygcheck -s -v -r' output, but it's not very informative. It's cut off after 10 lines or so. -- 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/
