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: "hans_boehm at hp dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Sep 2003 18:25:17 -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 hans_boehm at hp dot com 2003-09-09 18:25 -------
Subject: RE: [3.3/3.4 regression] [win32] garbage colle
ction crash in GCJ
> From: oyvind dot harboe at zylin dot com
> Would it be any help if this was reproducible w/WINE under Linux?
Probably not. I do have access to a Windows 2000 machine. I can run
statically linked executables.
I have no experience with mingw, and have been avoiding building a mingw
gcj. Unfortunately, I think someone may need to do that, since
the standard build seems to be lacking some important debug facilities.
If someone can send me a statically linked version of the executable,
preferably with debug info for boehm-gc and GETENV support enabled, that
might help. (I have the MS debugger and cygwin gdb. Debug info is
probably only immediately useful if one of those can deal with it.)
...
>
> Yes. At least three single CPU machines: AMD 1800, Pentium
> III 400, AMD 800.
Good. That eliminates the possibility of a missing lock prefix
or something similar. The symptom seems to be consistent with
dysfunctional locking in the allocator.
>
> >I just tried setting GC_PRINT_STATS in Windows 2000 with
> "set GC_PRINT_STATS=1"
> >from the Windows command line. That does seem to work, at
> least with the
> >standalone collector compiled with VC++, though the output
> ends up in the
> >file "gc.log", not on the screen. I suspect that means the
> other environment
> >variables will also do the right thing.
>
> I suppose I need to build boehm-gc with this enabled...
>
Yuck. Unfortunately that's correct. Configure.in in boehm-gc
defines NO_GETENV for win32, ostensibly because Wine getenv doesn't
always return NULL for missing entries. According to
http://gcc.gnu.org/ml/java-patches/2002-q1/msg00701.html it
returns empty strings instead.
This is clearly a bug in Wine. (It violates the C89
standard, among other things.) I'll submit a patch to the java
list with a better workaround, though I'm hoping that someone will
tell me that the Wine bug has been fixed.
Hans