This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: gcc problem: cygwin_except_handler STATUS_ACCESS_VIOL
- TO: pfay at acl dot lanl dot gov
- Subject: Re: gcc problem: cygwin_except_handler STATUS_ACCESS_VIOL
- From: HEINZ_SCHWEITZER at HP-Germany-om15 dot om dot hp dot com
- Date: Wed, 21 Jan 98 11:04:38 +0100
- CC: heinz_schweitzer at hp dot com, gnu-win32 at cygnus dot com, nordwick at graft dot XCF dot Berkeley dot EDU
Hi Jason, Patrick
Thanks for your help so far but I think I am to stupid to report a problem
the correct way. In my first posting I missed to report the very first line
of the output from gcc, please see below.
C:\home\hgs\src\rrr\code>gcc mmm.c
(unknown) heap_init: unable to allocate heap, win32 error 87
cygwin: terminating
The rest is still the same output and gcc goes into an endless loop
printing the same error messages.
Anyway does this help a bit more to find the problem. I still have no clue.
Sorry for wasting your time.
Cheers
Heinz Schweitzer
______________________________ Reply Separator _________________________________
Subject: Re: gcc problem: cygwin_except_handler STATUS_ACCESS_VIOL
Author: Non-HP-pfay (pfay@acl.lanl.gov) at HP-Germany,mimegw2
Date: 21.01.98 09:15
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 2
40EE5C
(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_di
splay]\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<pccnt;i++)
{
str=pcarr[i];
print "objdump -d --source --line-numbers --start-address=" str;
pcpart = substr(str,index(str,"x")+1);
syscmd="objdump -d --source --line-numbers --start-address=" pcarr[i] " " p
rog_name " |head -" display_lines;
system(syscmd);
close(syscmd);
}
}
/cygwin_except_handler/{
i=index($0," at ");
str=substr($0,i+4);
arrc=split(str,arr);
pc="0x" arr[1];
print "pc=" pc;
pccnt++;
pcarr[pccnt]=pc;
}
/ pc = /{
i=index($0," pc = ");
str=substr($0,i+5);
arrc=split(str,arr);
pc=arr[1];
print "pc=" pc;
pccnt++;
pcarr[pccnt]=pc;
}
/pfay/bin 340 >
To run it, copy the abend message to a file. then do
./trace_back ./tstc.exe abend_file_name [optionally_the_number_of_lines_to_displ
ay]
and you get an assembly dump (and if it was compiled with -g, the source code):
(Note that the dll's aren't found by trace_back.)
/pfay/bin 342 > ./tstc.exe >& tmp.jnk # to put the abend message in tmp.jnk
/pfay/bin 343 > ./trace_back tstc.exe tmp.jnk 30
#ARGS=4 prognm=tstc.exe,abend_msg_file=tmp.jnk,display 30 lines
pc=0x401076
pc=0x10007BB2
pc=0x77F94512
pc=0x77F88EEB
pc=0x77F76266
pc=0x4010BB
pc=0x100063BA
pc=0x100063CB
pc=0x401219
pc=0x40103B
pc=0x77F1B304
pc=0x0
objdump -d --source --line-numbers --start-address=0x401076
tstc.exe: file format pei-i386
Disassembly of section .text:
00401076 <.LM4+8>:
mysub():
/pfay/bin/tst.c:5
{
int j;
printf("Got to %s %d\n",__FILE__,__LINE__);
j = myi[-1000000];
401076: 8b 10 movl (%eax),%edx
401078: 89 55 fc movl %edx,0xfffffffc(%ebp)
0040107b <.LM5>:
/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 <function_name>'
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@cygnus.com" with one line of text: "help".
>
Patrick Fay, Ph.D., Intel Corp. email: pfay@co.intel.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@cygnus.com" with one line of text: "help".