From: pfay AT acl DOT lanl DOT gov (Patrick J. Fay) Subject: Re: gcc problem: cygwin_except_handler STATUS_ACCESS_VIOLATION,gdb,trace_back 22 Jan 1998 21:20:40 -0800 Message-ID: References: <199801181950 DOT LAA01684 AT graft DOT XCF DOT Berkeley DOT EDU> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: Jason Alan Nordwick Cc: Heinz Schweitzer , gnu-win32 AT cygnus DOT com Hello Jason, Heinz etc. Sorry if you already know this: try the debugger gdb. It works pretty well. Say I have the program tst.c: /pfay/bin 323 > cat tst.c int mysub(int *myi) { int j; printf("Got to %s %d\n",__FILE__,__LINE__); j = myi[-1000000]; return(j); } int main() { int i,j,myi[100]; printf("hello; begin\n"); mysub(myi); } and do: /pfay/bin 324 > gcc -g tst.c -o tstc /pfay/bin 326 > gdb -nw tstc.exe GNU gdb 4.16.1 Copyright 1997 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-cygwin32"... (gdb) run Starting program: /pfay/bin/tstc.exe 10000000:/WINNT/System32/cygwin.dll ....snip... #skip the dll messages... Program received signal SIGSEGV, Segmentation fault. 0x401076 in mysub (myi=0x240ed5c) at tst.c:5 5 j = myi[-1000000]; (gdb) bt #0 0x401076 in mysub (myi=0x240ed5c) at tst.c:5 #1 0x4010bb in main () at tst.c:12 #2 0x100063ba in dll_crt0_1 () #3 0x100063cb in dll_crt0 () #4 0x401219 in cygwin_crt0 () (gdb) Now this is much better than: /pfay/bin 327 > ./tstc hello; begin Got to tst.c 4 (c:\pfay\bin\tstc.exe 1895) In cygwin_except_handler exc C0000005 at 401076 sp 240EE5C (c:\pfay\bin\tstc.exe 1895) Exception trapped! (c:\pfay\bin\tstc.exe 1895) exception C0000005 at 401076 (c:\pfay\bin\tstc.exe 1895) exception: ax 203E56C bx 0 cx F dx FFFFFFFF (c:\pfay\bin\tstc.exe 1895) exception: si 240F25C di 5 bp 240EE60 sp 240EE5C (c:\pfay\bin\tstc.exe 1895) exception is: STATUS_ACCESS_VIOLATION (c:\pfay\bin\tstc.exe 1895) Stack trace: (c:\pfay\bin\tstc.exe 1895) frame 0: sp = 0x240EC90, pc = 0x10007BB2 (c:\pfay\bin\tstc.exe 1895) frame 1: sp = 0x240ECAC, pc = 0x77F94512 (c:\pfay\bin\tstc.exe 1895) frame 2: sp = 0x240ECD0, pc = 0x77F88EEB (c:\pfay\bin\tstc.exe 1895) frame 3: sp = 0x240ED5C, pc = 0x77F76266 (c:\pfay\bin\tstc.exe 1895) frame 4: sp = 0x240EE60, pc = 0x4010BB (c:\pfay\bin\tstc.exe 1895) frame 5: sp = 0x240F004, pc = 0x100063BA (c:\pfay\bin\tstc.exe 1895) frame 6: sp = 0x240FF94, pc = 0x100063CB (c:\pfay\bin\tstc.exe 1895) frame 7: sp = 0x240FFA0, pc = 0x401219 (c:\pfay\bin\tstc.exe 1895) frame 8: sp = 0x240FFB0, pc = 0x40103B (c:\pfay\bin\tstc.exe 1895) frame 9: sp = 0x240FFC0, pc = 0x77F1B304 (c:\pfay\bin\tstc.exe 1895) frame 10: sp = 0x240FFF0, pc = 0x0 (c:\pfay\bin\tstc.exe 1895) End of stack trace If for some reason you can't run it under the debugger (say you are doing a post-mortem analysis) then you can use this trace_back utility: /pfay/bin 338 > cat trace_back #!/bin/sh gawk -f /pfay/bin/trace_back.awk $* /pfay/bin 339 > cat trace_back.awk BEGIN{ prog_name = ARGV[1]; abend_file = ARGV[2]; display_lines = ARGV[3]; if(display_lines+0==0){display_lines=30;} #print ARGC " " ARGV[3]; #line below is 'if(ARGC<3)' in html if(ARGC<3) { printf("usage: trace_back program_name abend_file_name [count_of_lines_to_display]\n",ARGV[0]); exit(0); } printf("#ARGS=%d prognm=%s,abend_msg_file=%s,display %d lines\n", ARGC,prog_name,abend_file, display_lines); ARGC=2; ARGV[1]=ARGV[2]; pccnt=0; } END{ #line below is: for(i=1;i<pccnt;i++) (in html) for(i=1;i: /pfay/bin/tst.c:6 return(j); 40107b: 8b 55 fc movl 0xfffffffc(%ebp),%edx 40107e: 89 d0 movl %edx,%eax 401080: eb 00 jmp 401082 <.LM6> 00401082 <.LM6>: /pfay/bin/tst.c:7 } 401082: c9 leave 401083: c3 ret 401084: 68 65 6c 6c 6f pushl $0x6f6c6c65 401089: 3b 20 cmpl (%eax),%esp 40108b: 62 65 67 boundl 0x67(%ebp),%esp objdump -d --source --line-numbers --start-address=0x10007BB2 tstc.exe: file format pei-i386 Disassembly of section .text: objdump -d --source --line-numbers --start-address=0x77F94512 tstc.exe: file format pei-i386 Disassembly of section .text: objdump -d --source --line-numbers --start-address=0x77F88EEB tstc.exe: file format pei-i386 Disassembly of section .text: objdump -d --source --line-numbers --start-address=0x77F76266 tstc.exe: file format pei-i386 Disassembly of section .text: objdump -d --source --line-numbers --start-address=0x4010BB tstc.exe: file format pei-i386 Disassembly of section .text: 004010bb <.LM11+c>: main(): /pfay/bin/tst.c:12 int main() { int i,j,myi[100]; printf("hello; begin\n"); mysub(myi); 4010bb: 83 c4 04 addl $0x4,%esp 004010be <.LM12>: /pfay/bin/tst.c:13 } 4010be: c9 leave 4010bf: c3 ret 004010c0 <___do_global_dtors>: __do_global_dtors(): 4010c0: 55 pushl %ebp 4010c1: 89 e5 movl %esp,%ebp 4010c3: eb 0e jmp 4010d3 <___do_global_dtors+13> 4010c5: 90 nop 4010c6: 83 c0 04 addl $0x4,%eax 4010c9: a3 04 30 40 00 movl %eax,0x403004 4010ce: 8b 40 fc movl 0xfffffffc(%eax),%eax /pfay/bin 344 > If the program wasn't compiled with debug, then you still get the subroutine names. You can look for 'call ' type statements to try and get a context for where the assembly is in the source code. More than you ever wanted to know.... Pat On Sun, 18 Jan 1998, Jason Alan Nordwick wrote: > > Heinz Schweitzer, on Thu 1/15/1998, wrote the following: > > > > (unknown) In cygwin_except_handler > > (unknown) Exception trapped! > > (unknown) exception C0000005 at 1001E4B2 > > (unknown) exception: ax 0 bx 0 cx 6 dx 7 > > (unknown) exception: si 6779632D di 36383369 bp 241FB30 sp 241FB30 > > (unknown) exception is: STATUS_ACCESS_VIOLATION > > (unknown) Stack trace: > > (unknown) frame 0: sp = 0x241F964, pc = 0x1001282A > > (unknown) frame 1: sp = 0x241F980, pc = 0x77F94492 > > (unknown) frame 2: sp = 0x241F9A4, pc = 0x77F88E93 > > (unknown) frame 3: sp = 0x241FA30, pc = 0x77F76202 > > (unknown) frame 4: sp = 0x241FB30, pc = 0x10011D4D > > (unknown) frame 5: sp = 0x241FB44, pc = 0x10018972 > > (unknown) frame 6: sp = 0x241FB5C, pc = 0x10011615 > > (unknown) frame 7: sp = 0x241FF94, pc = 0x10011BFF > > (unknown) frame 8: sp = 0x241FFA0, pc = 0x4118D5 > > (unknown) frame 9: sp = 0x241FFB0, pc = 0x40103B > > (unknown) frame 10: sp = 0x241FFC0, pc = 0x77F1B26B > > (unknown) frame 11: sp = 0x241FFF0, pc = 0x0 > > (unknown) End of stack trace > > (unknown) In cygwin_except_handler > > (unknown) Error while dumping state (probably corrupted stack) > > > > > When I got that error yesterday, it took me two hours to > figure out that it was the same as SIGBUS. I was being stoopid > and derefing a NULL pointer. > > doesn't look like the same problem, but is that always the case ? > It has nothing to do with a stack corruption, did it ? > > jay > -- > Join the FreeBSD Revolution. > Support the FSF, buy GNU. > http://xcf.berkeley.edu/ > - > For help on using this list (especially unsubscribing), send a message to > "gnu-win32-request AT cygnus DOT com" with one line of text: "help". > Patrick Fay, Ph.D., Intel Corp. email: pfay AT co DOT intel DOT com Los Alamos National Lab wk: (505) 665-9141 CTI M.S. B296 fax: (505) 667-5921 Los Alamos NM 87545 ASCI-RED http://www.acl.lanl.gov/~pfay/teraflop - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".