Mail Archives: cygwin/2005/03/11/08:27:58
----Original Message----
>From: David Dindorp
>Sent: 11 March 2005 12:23
> Description:
> Bash crashes and leaves a stack dump file.
>
> Wanted:
> Help debugging, information, hints.
> Crash location:
> /netrel/src/cygwin-snapshot-20050309-1/winsup/cygwin/pinfo.h:178
Here's how to find out what was on a given line of a given source file of
cygwin on a given day (assuming you have a locally checked-out copy of the
CVS, and you have cd'd into the winsup/cygwin dir):
dk AT mace /usr/build/src/winsup/cygwin> cvs update -p -D 20050309 pinfo.h |
cat -n | less -c
which shows me.......
178 _pinfo *operator -> () const {return procinfo;}
that we appear to have crashed in an overloaded dereference operator,
> Exception:
> STATUS_ACCESS_VIOLATION at eip=61056EBC in pinfo.h:178
Here's how you could find out what instruction that was:
dk AT mace /usr/build/src/winsup/cygwin> objdump -dstrz /bin/cygwin1.dll | grep
-i 61056ebc
61056ebc
61056ebc: e9 4c ff ff ff jmp 61056e0d <_chdir+0xdd>
Hmm, my build of the dll must differ from yours.
> Versions:
> Cygwin snapshot 2005-03-09
> Bash 2.05b-17
>
> Cpu:
> cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
> eax=42315F0B ebx=00000000 ecx=0A030000 edx=00000000
> esi=0022D440 edi=00000148 ebp=0022D4F8 esp=0022D3E0
>
> Stack trace:
> Frame Function Address Args
> 0022D4F8 61056EBC pinfo.h:178 (0022D650,0022D654,0022D658,0022D500)
> 0022D678 610577ED fork.cc:562 (000000FF,0022D698,0022D694,00000003)
So, what was on line 562 of fork.cc when that snapshot was built?
dk AT mace /usr/build/src/winsup/cygwin> cvs update -p -D 20050309 fork.cc 2>&1
| cat -n | less -c
1 cvs [update aborted]: end of file from server (consult above
messages if any)
Oh blast. It seems that the CVS server is forked..... this is usually a
transient error. Wait half an hour and try again:
558 int res = setjmp (ch.jmp);
559 if (res)
560 res = fork_child (grouped.hParent, grouped.first_dll,
grouped.load_dlls);
561 else
562 res = fork_parent (grouped.hParent, grouped.first_dll,
grouped.load_dlls, esp, ch);
563 sig_send (NULL, __SIGNOHOLD);
Hmm, it's not immediately obvious where the pinfo comes from in that... it
would take some looking into the structures involved.
> 0022D6A8 61093C8F ??:0 (00000000,00000000,0022D6DC,0A052758)
> 0022D708 00420C6E ??:0 (0A052758,00000000,0046A816,00000000)
> 0022D798 00423C93 ??:0 (0022D7D8,00000000,00000000,00000000)
> 0022D7B8 0041F4D0 ??:0 (0022D7D8,00000000,00000000,00000000)
> 0022D7E8 0041F58B ??:0 (0A088C60,00000000,0022D848,0040CDAF)
> 0022D808 0041F5E9 ??:0 (0A088C60,00000000,0022D85C,0A0857F8)
> 0022D828 0041F255 ??:0 (0A088C60,00000000,0041F5B0,0A054798)
> 0022D868 0041EE1B ??:0 (0A079658,00000001,0022D898,00424814)
> 0022D878 0041EEBA ??:0 (0A079658,0A083950,0022D8A8,00000001)
> 0022D898 00424814 ??:0 (0A054798,0000001F,0022D918,00410235)
> 0022D8A8 0042416A ??:0 (0A054798,0A07F310,0022D8E8,6105E692)
> 0022D918 00410235 ??:0 (0A068608,FFFFFFFF,FFFFFFFF,00000000)
> 0022D958 0040D8FF ??:0 (0A0685F0,00000000,FFFFFFFF,FFFFFFFF)
> 0022D988 0040D425 ??:0 (0A0685F0,0A0782B8,0022D9A8,00427282)
> End of stack trace (more stack frames may be present)
Now, these functions in the 004xxxxx range are part of the bash
executable. (In general, exe's live down at low addresses around 004x, and
dlls live higher up in memory from 500x to 7ffx, more-or-less). So what you
want to do next, if we can't guess from looking at the cygwin dll traceback,
is to get the sourcecode for bash too, and build and install it, so you'll
be able to look it up with debugging info and run addr2line on it and all
that.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
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 -