Mail Archives: cygwin/2005/03/11/14:23:27
Dave, can't thank you enough for your kind help.
I built a bash 2.05b-17 with debugging symbols,
that helps a lot in the stack trace dept.
For some reason, the debugging version crashed
right away - here's the updated stack trace.
Cut in two, otherwise my mailer would molest it.
(Not sure if I should just snip the stack frame
addresses and args pointers from the output -
they're not much good anyway when I don't have
a memory dump, are they?)
Exception:
STATUS_ACCESS_VIOLATION at eip=61056EBC in pinfo.h:178
Odd that it always dies at the same place..
Cpu:
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
eax=4231D284 ebx=00000000 ecx=0A030000 edx=00000000
esi=0022DD00 edi=000008A8 ebp=0022DDB8 esp=0022DCA0
Stack trace:
Frame Function Address
0022DDB8 61056EBC pinfo.h:178
0022DF38 610577ED fork.cc:562
0022DF68 61093C8F ??:0
0022DFD8 00413121 execute_cmd.c:2515
0022E018 00410108 execute_cmd.c:632
0022E068 004111C4 execute_cmd.c:1358
0022E098 004114F7 execute_cmd.c:1456
0022E0D8 00410352 execute_cmd.c:781
0022E108 0040FB64 execute_cmd.c:326
0022E148 00410315 execute_cmd.c:733
0022E178 00411344 execute_cmd.c:1450
0022E1B8 00410352 execute_cmd.c:781
0022E1E8 0040FB64 execute_cmd.c:326
0022E218 0041130D execute_cmd.c:1449
0022E258 00410352 execute_cmd.c:781
0022E288 0040FB64 execute_cmd.c:326
Same stack trace:
Address Args
pinfo.h:178 (0022DF10,0022DF14,0022DF18,0022DDC0)
fork.cc:562 (000000FF,0022DF58,0022DF54,0043B377)
??:0 (0A068540,00000000,0022DFA8,6105E692)
execute_cmd.c:2515 (0A066158,00000003,00000005,00000000)
execute_cmd.c:632 (0A066140,00000000,00000003,00000005)
execute_cmd.c:1358 (0A066298,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:1456 (0A066298,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:781 (0A066298,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:326 (0A066298,00000001,00000001,00000000)
execute_cmd.c:733 (0A0662C8,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:1450 (0A0662F8,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:781 (0A0662F8,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:326 (0A0662F8,0A0663D8,0022E208,0042B672)
execute_cmd.c:1449 (0A0663C0,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:781 (0A0663C0,00000000,FFFFFFFF,FFFFFFFF)
execute_cmd.c:326 (0A0663C0,00000000,00000000,00000000)
I worry a bit about line 326 and 781 occurring repeatedly.
If it's an endless loop that spans multiple functions,
the reason for it all could be far down the stack
trace..
I tried to resolve the last missing eip from above using
addr2line, with no luck. Looking at the source code for
execute_cmd.c, it calls make_child in line 2515, so that
could be the missing piece. The definition for make_child
is in both jobs.c and nojobs.c. Not sure which one it is.
The bash.exe I've built responds to the 'jobs' command, so
my guess is that it's compiled with job control, even
though I haven't specified 'enable-job-control' to it's
configure script. Both pieces of C code, along with
execute_cmd.c, is attached, in the hope that nobody has
to go out and find the source for themselves..
> Here's how to find out what was on a given line of a given
Thanks!
> 178 _pinfo *operator -> () const {return procinfo;}
> that we appear to have crashed in an overloaded dereference operator,
> 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);
fork_parent... What's that, a part of a fork operation that takes place
in a parent process?..
fork_parent does some pinfo stuff around line 385, but I've got no idea
how to decipher what it does.
If a failure in fork_parent is involved, why doesn't fork_parent show up
in between pinfo.h:178 and fork.cc:562 in the stack trace?
/me *looks puzzled*
384 int child_pid = cygwin_pid (pi.dwProcessId);
385 pinfo child (child_pid, 1);
386 child->start_time = time (NULL);
387 child->nice = myself->nice;
389 if (!child)
391 syscall_printf ("pinfo failed");
> (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).
Priceless, thanks.
--
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 -