This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcj/10746] [3.3/3.4 regression] [win32] garbage collection crash in GCJ
- From: "oyvind dot harboe at zylin dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Sep 2003 11:15:40 -0000
- Subject: [Bug libgcj/10746] [3.3/3.4 regression] [win32] garbage collection crash in GCJ
- References: <20030512122601.10746.oyvind.harboe@zylin.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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