This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pinfo.h crash (#)


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]