Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: pinfo.h crash (#) Date: Fri, 11 Mar 2005 20:23:02 +0100 Message-ID: <79F81D5F4790D344B05F489CE2AC8AB7147296@dubexdc03.dubex.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "David Dindorp" To: X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j2BJNGFA020533 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/