This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

[Bug libgcj/10746] [3.3/3.4 regression] [win32] garbage collection crash in GCJ


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10746



------- Additional Comments From oyvind dot harboe at zylin dot com  2003-09-08 11:15 -------
I've followed up on some of Hans comments as best as I could:

>If p is the suspicious object, it would be nice to print
>
>*GC_find_header(p), GC_is_marked(p), GC_gc_no

When the debugger stops in getClass, it has an pagefault because it is trying 
to access address 0. But by examining the call stack, I found the pointer to 
the object passed into getClass(0x1070fd8):

(gdb) set language c
(gdb) print *GC_find_header(0x1070fd8)
$1 = 10

(gdb) print GC_is_marked(0x1070fd8)
$2 = 0

(gdb) print GC_gc_no()

Program received signal SIGSEGV, Segmentation fault.
0x000053e4 in ?? ()

Error: The program being debugged was signaled while in a function called from 
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (at 0x53e4) will be 
abandoned.


>(I've never verified that this works correctly on Windows, but I think
>it should.  GC_DONT_GC and GC_PRINT_STATS may also be interesting.)

I don't think the Windows target supports these environment variables, it 
doesn't seem to when I tried.

Øyvind


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