User account creation filtered due to spam.

Bug 10746 - [3.3 regression] [win32] garbage collection crash in GCJ
Summary: [3.3 regression] [win32] garbage collection crash in GCJ
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 3.3
: P3 normal
Target Milestone: 3.3.3
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 10748 11656 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-12 12:26 UTC by oyvind.harboe
Modified: 2003-10-11 10:51 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Attempt at creating a patch to incorporate Ranjits SEH code in boehm-gc/mark.c (2.19 KB, patch)
2003-07-31 00:55 UTC, oyvind.harboe
Details | Diff
Snapshot of debug session for a different manifistation (121.89 KB, image/pjpeg)
2003-09-08 10:48 UTC, oyvind.harboe
Details
Trying to upload a static compiled version of the test program with debug info (878.18 KB, application/octet-stream)
2003-09-10 07:28 UTC, oyvind.harboe
Details
Part two of the file (207.77 KB, application/octet-stream)
2003-09-10 07:31 UTC, oyvind.harboe
Details
Annotated debugging log based on Oyvind's executable (4.72 KB, text/plain)
2003-09-15 23:59 UTC, Hans Boehm
Details
Proposed patch (517 bytes, patch)
2003-09-16 00:15 UTC, Hans Boehm
Details | Diff
Another annotated debugging log (1.96 KB, text/plain)
2003-09-19 01:16 UTC, Hans Boehm
Details
Combined patch (10.20 KB, patch)
2003-10-03 21:49 UTC, Hans Boehm
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dara Hazeghi 2003-05-12 10:26:08 UTC
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: aph@redhat.com, oyvind.harboe@zylin.com, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libgcj/10746: [3.3 regression] garbage collection crash in GCJ
Date: Mon, 12 May 2003 10:26:08 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=10746
 
 Hello,
 
 FWIW, I don't seem to be able to get this under i686-linux. Hmm...  
 Using 3.2, 3.3 branch (20030511) or mainline (20030511), I get:
 /tmp/dara/bin/gcj --main=Test Test.class -o test Test$1.class
 Test.class:0: warning: source file seen twice on command line and will  
 be compiled only once
 
 Are you _sure_ this problem still occurs with current sources (or am I  
 doing something really dumb in trying to reproduce it)? Thanks,
 
 Dara
 

Comment 1 oyvind.harboe 2003-05-12 12:26:01 UTC
Follow instructions in this posting, GCJ 3.3 crashes, GCJ works.

http://gcc.gnu.org/ml/java/2003-02/msg00516.html

Release:
GCC 3.3
Comment 2 Steven Bosscher 2003-05-12 12:32:23 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed.
    Does it happen on mainline as well???
Comment 3 oyvind.harboe 2003-05-12 20:02:58 UTC
From: =?iso-8859-1?Q?=D8yvind_Harboe?= <oyvind.harboe@zylin.com>
To: "'Dara Hazeghi'" <dhazeghi@yahoo.com>, <aph@redhat.com>,
	<gcc-gnats@gcc.gnu.org>
Cc:  
Subject: RE: libgcj/10746: [3.3 regression] garbage collection crash in GCJ
Date: Mon, 12 May 2003 20:02:58 +0200

 >
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&database=3D=
 g
 cc&pr=3D10746
 >=20
 > Hello,
 >=20
 > FWIW, I don't seem to be able to get this under i686-linux. Hmm... =20
 > Using 3.2, 3.3 branch (20030511) or mainline (20030511), I=20
 > get: /tmp/dara/bin/gcj --main=3DTest Test.class -o test Test$1.class
 > Test.class:0: warning: source file seen twice on command line=20
 > and will =20
 > be compiled only once
 >=20
 > Are you _sure_ this problem still occurs with current sources=20
 > (or am I  doing something really dumb in trying to reproduce it)?
 Thanks,
 
 I know for sure that it is much harder to reproduce under Linux, ref.
 Ranjits
 posting.
 
 I'm waiting for Mohans next GCJ 3.3 build to test more. The build I ran
 was:
 
 http://www.thisiscool.com/gcc33_mingw.htm
 
 =D8yvind
Comment 4 Mark Mitchell 2003-07-20 01:19:52 UTC
What is the current status of this bug?
Comment 5 oyvind.harboe 2003-07-21 06:56:26 UTC
I tried it again today with Mohans build 20030522
(http://www.thisiscool.com/gcc33_mingw.htm):

From GDB session:

(gdb) thread apply all bt

Thread 3 (thread 3920.0xf5c):
#0  0x7ffe0304 in ?? ()
#1  0x77e79ce1 in KERNEL32!GetConsoleTitleW () from /ecos-C/WINDOWS/system32/ker
nel32.dll
#2  0x77e950ff in WriteConsoleA () from /ecos-C/WINDOWS/system32/kernel32.dll
#3  0x0048d6dc in _ZN4java2io14FileDescriptor5writeEP6JArrayIcEii ()
#4  0x00439427 in _ZN4java2io20BufferedOutputStream5flushEv ()
#5  0x0043829a in _ZN4java2io11PrintStream5flushEv ()
#6  0x0043842a in _ZN4java2io11PrintStream5printEPNS_4lang6StringEb ()
#7  0x00438c41 in _ZN4java2io11PrintStream7printlnEPNS_4lang6StringE ()
#8  0x00401936 in Test.stressGB(java.lang.String) (thread=0xc7cb10) at Test.java
:50
#9  0x0040132f in Test$1.run() (this=0xc75fc0) at Test.java:33
#10 0x004076e8 in _ZN4java4lang6Thread3runEv ()
#11 0x004196f7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#12 0x00418cd2 in _Z12really_startPv@4 ()
#13 0x0046041f in thread_start@4 ()
#14 0x77e7d33b in RegisterWaitForInputIdle () from /ecos-C/WINDOWS/system32/kern
el32.dll

Thread 2 (thread 3920.0xf58):
#0  0x7ffe0304 in ?? ()
#1  0x77e75faa in WaitForMultipleObjects () from /ecos-C/WINDOWS/system32/kernel
32.dll
#2  0x00411762 in _ZN4java4lang6Object4waitExi ()
#3  0x00404289 in _ZN4java4lang6Object4waitEv ()
#4  0x00414139 in _ZN3gnu3gcj7runtime15FinalizerThread3runEv ()
#5  0x004196f7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#6  0x00418cd2 in _Z12really_startPv@4 ()
#7  0x0046041f in thread_start@4 ()
#8  0x77e7d33b in RegisterWaitForInputIdle () from /ecos-C/WINDOWS/system32/kern
el32.dll

Thread 1 (thread 3920.0xf54):
#0  0x0045eae3 in GC_mark_from ()
#1  0x010f3dc0 in ?? ()
#2  0x0045e67c in GC_mark_some ()
#3  0x0045c945 in GC_stopped_mark ()
#4  0x0045c577 in GC_try_to_collect_inner ()
#5  0x0045d651 in GC_collect_or_expand ()
#6  0x0045d6fa in GC_allocobj ()
#7  0x0042d440 in GC_generic_malloc_inner ()
#8  0x0042d521 in GC_generic_malloc ()
#9  0x0042d663 in GC_malloc_atomic ()
#10 0x00402c82 in _Jv_NewPrimArray ()
#11 0x0040715e in _ZN3gnu3gcj7runtime12StringBufferC1Ei ()
#12 0x00407129 in _ZN3gnu3gcj7runtime12StringBufferC1Ev ()
#13 0x0040153e in Test.replaceAll(java.lang.String, java.lang.String, java.lang.
String) (in=0x1134ee0, a=0x1134ec0, b=0xc73f90) at Test.java:17
#14 0x00401c1f in Test.stressGB(java.lang.String) (thread=0xc798e8) at Test.java
:59
#15 0x00401751 in Test.main(java.lang.String[]) (args=0xc77fe0) at Test.java:38
#16 0x0045898b in _ZN3gnu3gcj7runtime11FirstThread9call_mainEv ()
#17 0x00414482 in _ZN3gnu3gcj7runtime11FirstThread3runEv ()
#18 0x004196f7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#19 0x00403c61 in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b ()
#20 0x00403d9f in JvRunMain ()
#21 0x004012f2 in main (argc=1, argv=0x3d2430)
(gdb)
Comment 6 oyvind.harboe 2003-07-21 06:59:18 UTC
Forgot an important bit, which thread caused the exception...


Program received signal SIGSEGV, Segmentation fault.
0x0045eae3 in GC_mark_from ()
Comment 7 oyvind.harboe 2003-07-21 07:12:54 UTC
I've tested this on Mohans GCC 3.4, same result:


Program received signal SIGSEGV, Segmentation fault.
0x00410799 in _ZN4java4lang6Object8getClassEv ()
(gdb) thread apply all bt

Thread 3 (thread 2984.0xbac):
#0  _Unwind_SjLj_Register (fc=0x107fd48) at /datal/gcc/gcc/gcc/gthr-win32.h:523
#1  0x004419b8 in _ZN4java4util6Random4nextEi ()
#2  0x00441da6 in _ZN4java4util6Random10nextDoubleEv ()
#3  0x0040980e in _ZN4java4lang4Math6randomEv ()
#4  0x00401a1f in Test.stressGB(java.lang.String) (thread=0xc3b930) at Test.java
:57
#5  0x004012bf in Test$1.run() (this=0xc3dfd0) at Test.java:33
#6  0x004061b6 in _ZN4java4lang6Thread3runEv ()
#7  0x004198d7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#8  0x00418e70 in _Z12really_startPv@4 ()
#9  0x004632ce in thread_start@4 ()
#10 0x77e7d33b in RegisterWaitForInputIdle () from /ecos-C/WINDOWS/system32/kern
el32.dll

Thread 2 (thread 2984.0xa84):
#0  0x7ffe0304 in ?? ()
#1  0x77e75faa in WaitForMultipleObjects () from /ecos-C/WINDOWS/system32/kernel
32.dll
#2  0x00411573 in _ZN4java4lang6Object4waitExi ()
#3  0x004057a9 in _ZN4java4lang6Object4waitEv ()
#4  0x0041403f in _ZN3gnu3gcj7runtime15FinalizerThread3runEv ()
#5  0x004198d7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#6  0x00418e70 in _Z12really_startPv@4 ()
#7  0x004632ce in thread_start@4 ()
#8  0x77e7d33b in RegisterWaitForInputIdle () from /ecos-C/WINDOWS/system32/kern
el32.dll

Thread 1 (thread 2984.0xba4):
#0  0x00410799 in _ZN4java4lang6Object8getClassEv ()
#1  0x004013ff in Test.replaceAll(java.lang.String, java.lang.String, java.lang.
String) (in=0x10f9000, a=0x1082fd8, b=0xc3efd8) at Test.java:11
#2  0x00401bae in Test.stressGB(java.lang.String) (thread=0xc3b960) at Test.java
:59
#3  0x004016e1 in Test.main(java.lang.String[]) (args=0xc36fe0) at Test.java:38
#4  0x004144b2 in _ZN3gnu3gcj7runtime11FirstThread3runEv ()
#5  0x004198d7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#6  0x0040389f in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b ()
#7  0x0040396f in JvRunMain ()
#8  0x00401282 in main (argc=1, argv=0x3d2430)
(gdb)
Comment 8 oyvind.harboe 2003-07-23 21:06:40 UTC
Hans Boehm has had a look at this, and it appears to be Windows specific.

http://gcc.gnu.org/ml/java/2003-07/msg00240.html
Comment 9 Mark Mitchell 2003-07-23 23:38:30 UTC
Win32 is not a primary evaluation platform.
Comment 10 oyvind.harboe 2003-07-24 09:02:35 UTC
I've made a slightly different version of my test program.

I saw an intriguing difference in behaviour: it produced a null pointer 
exception instead of a GP fault.

When I tried to catch the problem in GDB, I got the stack trace below, which 
smells different than what I've seen before.


Program received signal SIGSEGV, Segmentation fault.
0x00434325 in _ZN4java4lang6System9arraycopyEPNS0_6ObjectEiS3_ii ()
(gdb) thread apply all bt

Thread 3 (thread 2932.0xc98):
#0  0x7ffe0304 in ?? ()
#1  0x0042d523 in GC_malloc_atomic ()
#2  0x004029e3 in _Jv_AllocPtrFreeObject ()
#3  0x0040bc60 in _Jv_AllocString ()
#4  0x0040bc96 in _Jv_NewString ()
#5  0x004013e9 in Test.replaceAll(java.lang.String, java.lang.String, java.lang.
String) (in=0xec86a0, a=0xec8680, b=0xc73f90) at Test.java:10
#6  0x00401a9d in Test.stressGB(java.lang.String) (thread=0xc7cb10) at Test.java
:62
#7  0x004012cf in Test$1.run() (this=0xc75fc0) at Test.java:34
#8  0x004075a8 in _ZN4java4lang6Thread3runEv ()
#9  0x004195b7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#10 0x00418b92 in _Z12really_startPv@4 ()
#11 0x004602df in thread_start@4 ()
#12 0x77e7d33b in RegisterWaitForInputIdle () from /ecos-C/WINDOWS/system32/kern
el32.dll

Thread 2 (thread 2932.0x9dc):
#0  0x7ffe0304 in ?? ()
#1  0x77e75faa in WaitForMultipleObjects () from /ecos-C/WINDOWS/system32/kernel
32.dll
#2  0x00411622 in _ZN4java4lang6Object4waitExi ()
#3  0x00404149 in _ZN4java4lang6Object4waitEv ()
#4  0x00413ff9 in _ZN3gnu3gcj7runtime15FinalizerThread3runEv ()
#5  0x004195b7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#6  0x00418b92 in _Z12really_startPv@4 ()
#7  0x004602df in thread_start@4 ()
#8  0x77e7d33b in RegisterWaitForInputIdle () from /ecos-C/WINDOWS/system32/kern
el32.dll

Thread 1 (thread 2932.0x4b4):
#0  0x00434325 in _ZN4java4lang6System9arraycopyEPNS0_6ObjectEiS3_ii ()
#1  0x00406fb4 in _ZN3gnu3gcj7runtime12StringBuffer29ensureCapacity_unsynchroniz
edEi ()
#2  0x00406f04 in _ZN3gnu3gcj7runtime12StringBuffer6appendEPN4java4lang6StringE
()
#3  0x00401455 in Test.replaceAll(java.lang.String, java.lang.String, java.lang.
String) (in=0x10f3630, a=0x10f3610, b=0xc73f90) at Test.java:13
#4  0x00401a9d in Test.stressGB(java.lang.String) (thread=0xc79938) at Test.java
:62
#5  0x004016ef in Test.main(java.lang.String[]) (args=0xc77fe0) at Test.java:39
#6  0x0045884b in _ZN3gnu3gcj7runtime11FirstThread9call_mainEv ()
#7  0x00414342 in _ZN3gnu3gcj7runtime11FirstThread3runEv ()
#8  0x004195b7 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#9  0x00403b21 in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b ()
#10 0x00403c5f in JvRunMain ()
#11 0x00401292 in main (argc=1, argv=0x3d2440) at C:/DOCUME~1/oyvind/LOCALS~1/Te
mp/cc4Ucaaa.i:11
(gdb)


public class Test
{
	static public String replaceAll(String in, String a, String b)
	{
		String t = "";
		int i;
		i = 0; 
		while (i < in.length() - a.length())
		{
			String c = in.substring(i, i + a.length());
			if (c.equals(a))
			{
				t += b;
				i = i + a.length();
			} else
			{
				t += in.substring(i, i + 1);
				i++;
			}
		}
		if (i < in.length())
		{
			t += in.substring(i, in.length());
		}
		return t;
	}

	public static void main(String[] args)
	{
		Thread tr = new Thread(new Runnable()
		{
			public void run()
			{
				stressGB("second thread");
			}
		});
		tr.start();

		stressGB("first thread");

	}

	static final char[] abs = { 'a', 'b', 'c', 'd', 'e', 'f', 'g' };
	static char rndChar()
	{
		double r = Math.random();
		return abs[Math.min(abs.length - 1, (int) (r * abs.length ))];
	}

	static void stressGB(String thread)
	{

		String foo = "";
		for (int i = 0; i < 100000000; i++)
		{
			if ((i % 1000) == 0)
			{
				System.out.println(thread + " " + i + " " + 
foo);
			}

			foo = foo + rndChar();
			foo = replaceAll(foo, "" + rndChar(), "");
		}
	}
}
Comment 11 Andrew Pinski 2003-07-24 11:19:19 UTC
Also happens in 3.4 from bug 11656.
Comment 12 Andrew Pinski 2003-07-24 11:20:39 UTC
*** Bug 11656 has been marked as a duplicate of this bug. ***
Comment 13 oyvind.harboe 2003-07-25 11:47:40 UTC
No big news, just more evidence that this is a Windows specific problem:

- I've got RedHat 9 running on a 200MHz PPro w/128 MB ram. Works like a 
charm. :-)
- Downloaded the latest GCC 3.4
- ran configure + make
- gcj -static --main=Test -o test Test.java
- Ran ./test for ~1 hour. No GP or other visible problems.

I did run into something unexpected when I tried to run the test app from GDB 
under Linux, but thats probably just my limited linux skills... Or its most 
certainly something unrelated. The application recieves a "signal" as soon as I 
launch it.

[oyvind@fury test]$ gdb test
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 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-redhat-linux-gnu"...run

(gdb) run
Starting program: /home/oyvind/gcc/test/test

Program received signal SIG32, Real-time event 32.
0x08167799 in sigsuspend ()
(gdb) bt
#0  0x08167799 in sigsuspend ()
#1  0xbfffd850 in ?? ()
#2  0x08152835 in __pthread_wait_for_restart_signal ()
#3  0x08152a93 in pthread_create ()
#4  0x080bfa04 in GC_pthread_create (new_thread=0xfffffffc, attr=0xbfffda00,
    start_routine=0xfffffffc, arg=0xfffffffc)
    at ../../../gcc-3.4-20030723/boehm-gc/linux_threads.c:1424
#5  0x080b9c27 in _Jv_ThreadStart(java::lang::Thread*, _Jv_Thread_t*, void (*)(j
ava::lang::Thread*)) (thread=0x834fc80, data=0x8356e20, meth=0xfffffffc)
    at ../../../gcc-3.4-20030723/libjava/posix-threads.cc:424
#6  0x0807b6ff in java::lang::Thread::start() (this=0x8392ff8)
    at ../../../gcc-3.4-20030723/libjava/java/lang/natThread.cc:316
#7  0x08049fea in _Jv_CreateJavaVM(void*) ()
    at ../../../gcc-3.4-20030723/libjava/prims.cc:935
#8  0x0804a06e in _Jv_RunMain(java::lang::Class*, char const*, int, char const**
, bool) (klass=0x824e440, name=0xbfffda00 "\001", argc=137719328,
    argv=0x834fc80, is_jar=false)
    at ../../../gcc-3.4-20030723/libjava/prims.cc:958
#9  0x0804a1ff in JvRunMain (klass=0xfffffffc, argc=-4, argv=0xfffffffc)
    at ../../../gcc-3.4-20030723/libjava/prims.cc:996
#10 0x0804820e in main (argc=1, argv=0xbfffdd64) at /tmp/ccWOni7Z.i:11
#11 0x08159dd7 in __libc_start_main ()
(gdb)


Comment 14 oyvind.harboe 2003-07-31 00:55:28 UTC
Created attachment 4528 [details]
Attempt at creating a patch to incorporate Ranjits SEH code in boehm-gc/mark.c

My GCC superpowers are rather limited, though with Mohans scripts I've been
able to build GCC.

I tried to copy over Ranjits support for SEH in mark.c(this attachment).

This patch seems to make the my test app more stable, though it still crashes.
See outputs below.

I interpret this evidence as us being hot on the trail of the problem, or that
the patch fixes part of the problem.


[lots of output deleted]
second thread 188000 eeega

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3376.0x770]
0x0045e663 in GC_mark_from () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:29
29	/datal/gcc/gcc/gcc/config/i386/cygwin.asm: No such file or directory.
	in /datal/gcc/gcc/gcc/config/i386/cygwin.asm
Current language:  auto; currently asm
(gdb) thread apply all bt

Thread 3 (thread 3376.0x31c):
#0  0x7ffe0304 in ?? ()
#1  0x77e79ce1 in KERNEL32!GetConsoleTitleW () from
/ecos-C/WINDOWS/system32/ker
nel32.dll
#2  0x77e950ff in WriteConsoleA () from /ecos-C/WINDOWS/system32/kernel32.dll
#3  0x0048d71c in _ZN4java2io14FileDescriptor5writeEP6JArrayIcEii () at
/datal/g
cc/gcc/gcc/config/i386/cygwin.asm:29
#4  0x00439e47 in _ZN4java2io20BufferedOutputStream5flushEv () at
/datal/gcc/gcc
/gcc/config/i386/cygwin.asm:29
#5  0x00438cba in _ZN4java2io11PrintStream5flushEv () at
/datal/gcc/gcc/gcc/conf
ig/i386/cygwin.asm:29
#6  0x00438e4a in _ZN4java2io11PrintStream5printEPNS_4lang6StringEb () at
/datal
/gcc/gcc/gcc/config/i386/cygwin.asm:29
#7  0x00439661 in _ZN4java2io11PrintStream7printlnEPNS_4lang6StringE () at
/data
l/gcc/gcc/gcc/config/i386/cygwin.asm:29
#8  0x00401a00 in Test.stressGB(java.lang.String) (thread=0xbccab0) at
Test.java
:59
#9  0x0040132f in Test$1.run() (this=0xbc5fc0) at Test.java:34
#10 0x00407608 in _ZN4java4lang6Thread3runEv () at
/datal/gcc/gcc/gcc/config/i38
6/cygwin.asm:29
#11 0x00419617 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at
/datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#12 0x00418bf2 in _Z12really_startPv@4 () at
/datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#13 0x0045ff9f in thread_start@4 () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm
:29
#14 0x77e7d33b in RegisterWaitForInputIdle () from
/ecos-C/WINDOWS/system32/kern
el32.dll

Thread 2 (thread 3376.0xd7c):
#0  0x7ffe0304 in ?? ()
#1  0x77e75faa in WaitForMultipleObjects () from
/ecos-C/WINDOWS/system32/kernel
32.dll
#2  0x00411682 in _ZN4java4lang6Object4waitExi () at
/datal/gcc/gcc/gcc/config/i
386/cygwin.asm:29
#3  0x004041a9 in _ZN4java4lang6Object4waitEv () at
/datal/gcc/gcc/gcc/config/i3
86/cygwin.asm:29
#4  0x00414059 in _ZN3gnu3gcj7runtime15FinalizerThread3runEv () at
/datal/gcc/gc
c/gcc/config/i386/cygwin.asm:29
#5  0x00419617 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at
/datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#6  0x00418bf2 in _Z12really_startPv@4 () at
/datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#7  0x0045ff9f in thread_start@4 () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm
:29
#8  0x77e7d33b in RegisterWaitForInputIdle () from
/ecos-C/WINDOWS/system32/kern
el32.dll

Thread 1 (thread 3376.0x770):
#0  0x0045e663 in GC_mark_from () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:2
9
#1  0x0106dfc0 in ?? ()
#2  0x0045e0bc in GC_mark_some_inner () at
/datal/gcc/gcc/gcc/config/i386/cygwin
.asm:29
#3  0x0045e391 in GC_mark_some () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:2
9
#4  0x0045c665 in GC_stopped_mark () at
/datal/gcc/gcc/gcc/config/i386/cygwin.as
m:29
#5  0x0045c297 in GC_try_to_collect_inner () at
/datal/gcc/gcc/gcc/config/i386/c
ygwin.asm:29
#6  0x0045d1f1 in GC_collect_or_expand () at
/datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#7  0x0045d29a in GC_allocobj () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:29

#8  0x0042d360 in GC_generic_malloc_inner () at
/datal/gcc/gcc/gcc/config/i386/c
ygwin.asm:29
#9  0x0042d441 in GC_generic_malloc () at
/datal/gcc/gcc/gcc/config/i386/cygwin.
asm:29
#10 0x0042d583 in GC_malloc_atomic () at
/datal/gcc/gcc/gcc/config/i386/cygwin.a
sm:29
#11 0x00402ba2 in _Jv_NewPrimArray () at
/datal/gcc/gcc/gcc/config/i386/cygwin.a
sm:29
#12 0x00406fec in
_ZN3gnu3gcj7runtime12StringBuffer29ensureCapacity_unsynchroniz
edEi () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:29
#13 0x00406f64 in _ZN3gnu3gcj7runtime12StringBuffer6appendEPN4java4lang6StringE

() at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:29
#14 0x0040155c in Test.replaceAll(java.lang.String, java.lang.String,
java.lang.
String) (in=0x1063240, a=0x1063220, b=0xbc3f90) at Test.java:17
#15 0x00401afd in Test.stressGB(java.lang.String) (thread=0xbc9938) at
Test.java
:63
#16 0x0040174f in Test.main(java.lang.String[]) (args=0xbc7fe0) at Test.java:39

#17 0x004586ab in _ZN3gnu3gcj7runtime11FirstThread9call_mainEv () at
/datal/gcc/
gcc/gcc/config/i386/cygwin.asm:29
#18 0x004143a2 in _ZN3gnu3gcj7runtime11FirstThread3runEv () at
/datal/gcc/gcc/gc
c/config/i386/cygwin.asm:29
#19 0x00419617 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at
/datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#20 0x00403b81 in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b () at
/datal/gcc/g
cc/gcc/config/i386/cygwin.asm:29
#21 0x00403cbf in JvRunMain () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:29
#22 0x004012f2 in main (argc=1, argv=0x3d2430)
(gdb)



Second output:


Exception in thread "main" second thread 454000 dbecbfbf
second thread 455000 fddegffad
second thread 456000 gbegfagg
second thread 457000 baggcde
second thread 458000 eecdfc
second thread 459000 aaafcccgb
second thread 460000 eeebedb
second thread 461000 ddddddebd
second thread 462000 agcc
second thread 463000 gcccb
second thread 464000 bbbbbbdca
second thread 465000 aaaaaccfde
second thread 466000 cccbbde
second thread 467000 dgada
second thread 468000 eeggga
second thread 469000 gcggbcbab
second thread 470000 bbffge
second thread 471000 fffee
second thread 472000 bbbgaf
second thread 473000 bbegefg
second thread 474000 ffffac
second thread 475000 cccccfb
second thread 476000 efaag
second thread 477000 cdcd
second thread 478000 ffefc
second thread 479000 gbbggbdfeeg
second thread 480000 bbbddeedg
second thread 481000 gggcffa
second thread 482000 cccbbdbb
second thread 483000 bbeaab
second thread 484000 cccfcddgg
second thread 485000 ggggadad
second thread 486000 aaaaaaadffaadg
second thread 487000 aaddgfac
second thread 488000 geeggaaag
second thread 489000 gcdgge
second thread 490000 fbbgge
second thread 491000 aafaaddffedfc
second thread 492000 dccdfddgd
second thread 493000 efdb
second thread 494000 fgffbd
second thread 495000 aaaaaacb
second thread 496000 cdc
second thread 497000 eeedaaaeebaee
second thread 498000 ddccfae
second thread 499000 dddgdgde
second thread 500000 fcffgb
second thread 501000 ccgdee
second thread 502000 gdceef
second thread 503000 aee
second thread 504000 ccdgce
second thread 505000 bcccbceda
second thread 506000 bbdagage
second thread 507000 aggf
java.lang.ArrayStoreException
   at 0x00417200 (Unknown Source)
   at 0x00416be4 (Unknown Source)
   at 0x00416bb5 (Unknown Source)
   at 0x004343cb (Unknown Source)
   at 0x00407010 (Unknown Source)
   at 0x00406e2f (Unknown Source)
   at 0x00401ac6 (Unknown Source)
   at 0x0040174b (Unknown Source)
   at 0x004586a7 (Unknown Source)
   at 0x0041439e (Unknown Source)
   at 0x00419613 (Unknown Source)
   at 0x00403b7d (Unknown Source)
   at 0x00403cbb (Unknown Source)
   at 0x004012ee (Unknown Source)
   at 0x0040117e (Unknown Source)
   at 0x00401014 (Unknown Source)
   at 0x7second thread 508000 fbabfaaead
7e814c3 (Unknown Source)
second thread 509000 aaadaccabf
second thread 510000 eeebbecbff
second thread 511000 fggc
second thread 512000 ccef
second thread 513000 aaadedadb
second thread 514000 bcbdcag
second thread 515000 ecccbcbd
second thread 516000 ececedbdde
second thread 517000 gggfce
second thread 518000 ebcbe
second thread 519000 dgfgdf
second thread 520000 fgca
second thread 521000 ddgcga
second thread 522000 gccgbcd
second thread 523000 bbbbeggegf
second thread 524000 bebeffebce
second thread 525000 cabea
second thread 526000 dgf
second thread 527000 ccgcac
second thread 528000 ddaagab
second thread 529000 aeeee
second thread 530000 fbggd
second thread 531000 deeeg
second thread 532000 eecacg
second thread 533000 dcddecb
second thread 534000 fffcacbeac
second thread 535000 fffaacg
second thread 536000 bbbcbfc
second thread 537000 aeeaaeeacaec
second thread 538000 aaaadaaccc
second thread 539000 fffefc
second thread 540000 ddddgffgefef
second thread 541000 bbdbg
second thread 542000 ddfcdfgfgga
second thread 543000 acdc
second thread 544000 ccddg
second thread 545000 ccccffffcafdgag
second thread 546000 fccdgc
second thread 547000 fdeeg
second thread 548000 efbbbd
second thread 549000 ggcgcbdb
second thread 550000 fgdb
second thread 551000 cccdgadg
second thread 552000 ggafd
second thread 553000 ffcddbe
second thread 554000 aeb
second thread 555000 debbd
second thread 556000 bgab
second thread 557000 cgag
second thread 558000 bcfa
second thread 559000 fdfb
second thread 560000 bbeeaee
second thread 561000 fcaaddd
second thread 562000 bfggbgbfdbc
second thread 563000 edfc
second thread 564000 cgceag
second thread 565000 dddfecfaca
second thread 566000 ccdaedg
second thread 567000 ddbgabf
second thread 568000 dbaabe
second thread 569000 bbfbffdfdd
second thread 570000 cdgag
second thread 571000 dbdddbgg
second thread 572000 gdegad
second thread 573000 bebcee
second thread 574000 aaacceceab
second thread 575000 eeeabaeee
second thread 576000 dfaad
second thread 577000 gedfg
second thread 578000 feeddbd
second thread 579000 cbbbcag
second thread 580000 bggbac
second thread 581000 aecce
second thread 582000 aaddaadef
second thread 583000 efffegca
second thread 584000 ccccebc
second thread 585000 bbeege
second thread 586000 cbccgggb

Program received signal SIGINT, Interrupt.
[Switching to thread 1932.0xf80]
0x77ea31c7 in KERNEL32!GetAtomNameA () from
/ecos-C/WINDOWS/system32/kernel32.dl
l
(gdb) thread apply all bt

Thread 4 (thread 1932.0xf80):
#0  0x77ea31c7 in KERNEL32!GetAtomNameA () from
/ecos-C/WINDOWS/system32/kernel3
2.dll
#1  0x77f57d70 in ntdll!RtlAppendStringToString () from ntdll.dll
#2  0x77e7d33b in RegisterWaitForInputIdle () from
/ecos-C/WINDOWS/system32/kern
el32.dll

Thread 3 (thread 1932.0x658):
#0  0x7ffe0304 in ?? ()
#1  0x004b2d99 in GC_push_roots () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:
29
#2  0x0045e10b in GC_mark_some_inner () at
/datal/gcc/gcc/gcc/config/i386/cygwin
.asm:29
#3  0x0045e391 in GC_mark_some () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:2
9
#4  0x0045c665 in GC_stopped_mark () at
/datal/gcc/gcc/gcc/config/i386/cygwin.as
m:29
#5  0x0045c297 in GC_try_to_collect_inner () at
/datal/gcc/gcc/gcc/config/i386/c
ygwin.asm:29
#6  0x0045d1f1 in GC_collect_or_expand () at
/datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#7  0x0045d29a in GC_allocobj () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:29

#8  0x0042d360 in GC_generic_malloc_inner () at
/datal/gcc/gcc/gcc/config/i386/c
ygwin.asm:29
#9  0x0042d441 in GC_generic_malloc () at
/datal/gcc/gcc/gcc/config/i386/cygwin.
asm:29
#10 0x0042d583 in GC_malloc_atomic () at
/datal/gcc/gcc/gcc/config/i386/cygwin.a
sm:29
#11 0x00402ba2 in _Jv_NewPrimArray () at
/datal/gcc/gcc/gcc/config/i386/cygwin.a
sm:29
#12 0x0040707e in _ZN3gnu3gcj7runtime12StringBufferC1Ei () at
/datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#13 0x00407049 in _ZN3gnu3gcj7runtime12StringBufferC1Ev () at
/datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#14 0x0040153c in Test.replaceAll(java.lang.String, java.lang.String,
java.lang.
String) (in=0x107e340, a=0x107e320, b=0xbc3f90) at Test.java:17
#15 0x00401afd in Test.stressGB(java.lang.String) (thread=0xbccab0) at
Test.java
:63
#16 0x0040132f in Test$1.run() (this=0xbc5fc0) at Test.java:34
#17 0x00407608 in _ZN4java4lang6Thread3runEv () at
/datal/gcc/gcc/gcc/config/i38
6/cygwin.asm:29
#18 0x00419617 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at
/datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#19 0x00418bf2 in _Z12really_startPv@4 () at
/datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#20 0x0045ff9f in thread_start@4 () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm
:29
#21 0x77e7d33b in RegisterWaitForInputIdle () from
/ecos-C/WINDOWS/system32/kern
el32.dll

Thread 2 (thread 1932.0x968):
#0  0x7ffe0304 in ?? ()
#1  0x77e75faa in WaitForMultipleObjects () from
/ecos-C/WINDOWS/system32/kernel
32.dll
#2  0x00411682 in _ZN4java4lang6Object4waitExi () at
/datal/gcc/gcc/gcc/config/i
386/cygwin.asm:29
#3  0x004041a9 in _ZN4java4lang6Object4waitEv () at
/datal/gcc/gcc/gcc/config/i3
86/cygwin.asm:29
#4  0x00414059 in _ZN3gnu3gcj7runtime15FinalizerThread3runEv () at
/datal/gcc/gc
c/gcc/config/i386/cygwin.asm:29
#5  0x00419617 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at
/datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#6  0x00418bf2 in _Z12really_startPv@4 () at
/datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#7  0x0045ff9f in thread_start@4 () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm
:29
#8  0x77e7d33b in RegisterWaitForInputIdle () from
/ecos-C/WINDOWS/system32/kern
el32.dll

Thread 1 (thread 1932.0x774):
#0  0x7ffe0304 in ?? ()
#1  0x77e7ac21 in WaitForSingleObject () from
/ecos-C/WINDOWS/system32/kernel32.
dll
#2  0x00403b86 in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b () at
/datal/gcc/g
cc/gcc/config/i386/cygwin.asm:29
#3  0x00403cbf in JvRunMain () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:29
#4  0x004012f2 in main (argc=1, argv=0x3d2430)
#0  0x77ea31c7 in KERNEL32!GetAtomNameA () from
/ecos-C/WINDOWS/system32/kernel3
2.dll
(gdb)
Comment 15 oyvind.harboe 2003-08-04 10:58:42 UTC
I ran a debug session with Mohans GCC 3.4 20030802 build where the 6.3 alpha 3 
gb collector has been included AFAICT.

Note that the structured exception handling was not introduced until alpha 4 or 
5(I should probably look up on the boehm-gc CVS server).


[output deleted]
second thread 1792000 eeeefefef
second thread 1793000 ccdccdbcddedfdg

Program received signal SIGSEGV, Segmentation fault.
0x00410a99 in _ZN4java4lang6Object8getClassEv ()
(gdb) thread apply all bt

Thread 3 (thread 776.0x644):
#0  0x77f88ad7 in ?? ()
#1  0x77eb9d39 in ReadConsoleW () from /ecos-c/WINNT/system32/KERNEL32.DLL
#2  0x77eb9dc1 in WriteConsoleA () from /ecos-c/WINNT/system32/KERNEL32.DLL
#3  0x00496a60 in _ZN4java2io14FileDescriptor5writeEP6JArrayIcEii ()
#4  0x0043f261 in _ZN4java2io16FileOutputStream5writeEP6JArrayIcEii ()
#5  0x0043eb4b in _ZN4java2io20BufferedOutputStream5flushEv ()
#6  0x00490071 in _ZN4java2io18OutputStreamWriter5flushEv ()
#7  0x0048eeea in _ZN4java2io11PrintWriter7printlnEv ()
#8  0x0048f5cd in _ZN4java2io11PrintWriter7printlnEPNS_4lang6StringE ()
#9  0x0043e5b2 in _ZN4java2io11PrintStream7printlnEPNS_4lang6StringE ()
#10 0x004019ef in Test.stressGB(java.lang.String) (thread=0xbbb900) at Test.java
:59
#11 0x0040131f in Test$1.run() (this=0xbbdfd0) at Test.java:34
#12 0x00406166 in _ZN4java4lang6Thread3runEv ()
#13 0x0041de67 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#14 0x0041d400 in _Z12really_startPv@4 ()
#15 0x0046769e in thread_start@4 ()
#16 0x77e8b2d8 in lstrcmpiW () from /ecos-c/WINNT/system32/KERNEL32.DLL

Thread 2 (thread 776.0x520):
#0  0x77f88e63 in ?? ()
#1  0x77ea9c13 in WaitForMultipleObjects () from /ecos-c/WINNT/system32/KERNEL32
.DLL
#2  0x00411873 in _ZN4java4lang6Object4waitExi ()
#3  0x00405759 in _ZN4java4lang6Object4waitEv ()
#4  0x0041435f in _ZN3gnu3gcj7runtime15FinalizerThread3runEv ()
#5  0x0041de67 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#6  0x0041d400 in _Z12really_startPv@4 ()
#7  0x0046769e in thread_start@4 ()
#8  0x77e8b2d8 in lstrcmpiW () from /ecos-c/WINNT/system32/KERNEL32.DLL

Thread 1 (thread 776.0x7ec):
#0  0x00410a99 in _ZN4java4lang6Object8getClassEv ()
#1  0x0040145e in Test.replaceAll(java.lang.String, java.lang.String, java.lang.
String) (in=0xe5d000, a=0x1073fd8, b=0xbbefd8) at Test.java:11
#2  0x00401aec in Test.stressGB(java.lang.String) (thread=0xbbb930) at Test.java
:63
#3  0x0040173d in Test.main(java.lang.String[]) (args=0xbb6fe0) at Test.java:39
#4  0x004147d2 in _ZN3gnu3gcj7runtime11FirstThread3runEv ()
#5  0x0041de67 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE ()
#6  0x0040381f in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b ()
#7  0x004038ef in JvRunMain ()
#8  0x004012e2 in main (argc=1, argv=0x702468)
(gdb)
Comment 16 oyvind.harboe 2003-08-15 09:50:13 UTC
I compiled and ran the test with the latest GCJ 3.4, but but it still crashes. 

I believe the chkstk function in cygwin.asm is a red herring and that the real 
problem is in the function disassembled below.





-	0x410a90	<_ZN4java4lang6Object8getClassEv>:		push   %
ebp
-	0x410a91	<_ZN4java4lang6Object8getClassEv+1>:		mov    %
esp,%ebp
-	0x410a93	<_ZN4java4lang6Object8getClassEv+3>:		mov    
0x8(%ebp),%eax
-	0x410a96	<_ZN4java4lang6Object8getClassEv+6>:		pop    %
ebp
-	0x410a97	<_ZN4java4lang6Object8getClassEv+7>:		mov    
(%eax),%eax
-	0x410a99	<_ZN4java4lang6Object8getClassEv+9>:		mov    
(%eax),%eax
-	0x410a9b	<_ZN4java4lang6Object8getClassEv+11>:		ret    
-	0x410a9c	<_ZN4java4lang6Object8getClassEv+12>:		lea    
0x0(%esi,1),%esi















[stuff deleted]
first thread 845000 cccfffbaad
second thread 1806000 ggfcace
second thread 1807000 ccdgbga
second thread 1808000 bcggc
second thread 1809000 caddbd

Program received signal SIGSEGV, Segmentation fault.
0x00410a99 in _ZN4java4lang6Object8getClassEv () at /datal/gcc/gcc/gcc/config/i3
86/cygwin.asm:29
29      /datal/gcc/gcc/gcc/config/i386/cygwin.asm: No such file or directory.
        in /datal/gcc/gcc/gcc/config/i386/cygwin.asm
Current language:  auto; currently asm
(gdb) thread apply all bt

Thread 3 (thread 2112.0x72c):
#0  0x0057c464 in _Unwind_SjLj_Register () at /datal/gcc/gcc/libffi/src/x86/win3
2.S:224
#1  0x004421d8 in _ZN4java4util6Random4nextEi () at /datal/gcc/gcc/gcc/config/i3
86/cygwin.asm:29
#2  0x004425e4 in _ZN4java4util6Random10nextDoubleEv () at /datal/gcc/gcc/gcc/co
nfig/i386/cygwin.asm:29
#3  0x0040986e in _ZN4java4lang4Math6randomEv () at /datal/gcc/gcc/gcc/config/i3
86/cygwin.asm:29
#4  0x0040176f in Test.rndChar() () at Test.java:46
#5  0x00401a40 in Test.stressGB(java.lang.String) (thread=0xb5b960) at Test.java
:62
#6  0x0040131f in Test$1.run() (this=0xb5dfd0) at Test.java:34
#7  0x00406166 in _ZN4java4lang6Thread3runEv () at /datal/gcc/gcc/gcc/config/i38
6/cygwin.asm:29
#8  0x0041df27 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at /datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#9  0x0041d4c0 in _Z12really_startPv@4 () at /datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#10 0x004670de in thread_start@4 () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm
:29
#11 0x77e8b2d8 in lstrcmpiW () from /ecos-c/WINNT/system32/KERNEL32.DLL

Thread 2 (thread 2112.0x850):
#0  0x77f88e63 in ?? ()
#1  0x77ea9c13 in WaitForMultipleObjects () from /ecos-c/WINNT/system32/KERNEL32
.DLL
#2  0x00411873 in _ZN4java4lang6Object4waitExi () at /datal/gcc/gcc/gcc/config/i
386/cygwin.asm:29
#3  0x00405759 in _ZN4java4lang6Object4waitEv () at /datal/gcc/gcc/gcc/config/i3
86/cygwin.asm:29
#4  0x0041441f in _ZN3gnu3gcj7runtime15FinalizerThread3runEv () at /datal/gcc/gc
c/gcc/config/i386/cygwin.asm:29
#5  0x0041df27 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at /datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#6  0x0041d4c0 in _Z12really_startPv@4 () at /datal/gcc/gcc/gcc/config/i386/cygw
in.asm:29
#7  0x004670de in thread_start@4 () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm
:29
#8  0x77e8b2d8 in lstrcmpiW () from /ecos-c/WINNT/system32/KERNEL32.DLL

Thread 1 (thread 2112.0x884):
#0  0x00410a99 in _ZN4java4lang6Object8getClassEv () at /datal/gcc/gcc/gcc/confi
g/i386/cygwin.asm:29
#1  0x0040145e in Test.replaceAll(java.lang.String, java.lang.String, java.lang.
String) (in=0x1043000, a=0x1048fd8, b=0xb5efd8) at Test.java:11
#2  0x00401aec in Test.stressGB(java.lang.String) (thread=0xb5b990) at Test.java
:63
#3  0x0040173d in Test.main(java.lang.String[]) (args=0xb56fe0) at Test.java:39
#4  0x00414892 in _ZN3gnu3gcj7runtime11FirstThread3runEv () at /datal/gcc/gcc/gc
c/config/i386/cygwin.asm:29
#5  0x0041df27 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE () at /datal/gcc/gcc/gcc
/config/i386/cygwin.asm:29
#6  0x0040381f in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b () at /datal/gcc/g
cc/gcc/config/i386/cygwin.asm:29
#7  0x004038ef in JvRunMain () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:29
#8  0x004012e2 in main (argc=1, argv=0x6a24d8)
(gdb)
Comment 17 oyvind.harboe 2003-08-20 06:36:20 UTC
These are not breaking news, but here are the results of various things that 
I've tried:

- The program does not have to be rewritten very much for the crash to go away. 
This I discovered as part of my attempts to further reduce the problem.
- The crash happens almost every time in the same place(getClass()), but there 
are a handful of other symptoms(null pointer exceptions, segmentation faults 
elsewhere in the program).
- I haven't managed to reproduce it under Linux using GCC 3.4(or any other 
version of GCC for that matter).
- It happens much more quickly when I run it from Insight than from the command 
line GDB. I have not run the test from Insight under Linux.
- I compiled GCC 3.4 with disable-hash-synchronization, same problem.
- I tried to compile GCC 3.4 with disable-java-gc, but I got compilation errors.

Really what this problem needs is someone with the required Windows/GCJ 
skillset to tackle it head on because it is fairly reproduceable.

Øyvind
Comment 18 oyvind.harboe 2003-08-20 08:05:09 UTC
With just a tiny bit of tickling, I was able to get GCC 3.4 to compile with 
disable-java-gc(replaced the non-existant GC_CreateThread with CreateThread in 
win32-threads.cc):

As expected, the crash does not seem happen with the GC disabled. I ran the 
latest example included in this bugreport 3x until the commit charge was >1.5GB 
from Insight and console version GDB.

There is a good chance this "workaround" is applicable to my application. 

Øyvind
Comment 19 rmathew 2003-08-21 06:16:25 UTC
FWIW, the test program does not crash for me even after repeated
attempts. I am using GCC 3.4 snapshot for Win32 dated 20030802 as 
available on Mohan's GCJ site: http://www.thisiscool.com/gcc_mingw.htm
(This snapshot has Boehm-GC 6.3 alpha 1.)

My machine is running Win2K with SP4 on a P4/1.7GHz with
512MB RAM.

I would also like to point out that getting a SEGV in the GC
while running inside a debugger is common and expected as
noted in this GCJ FAQ entry:

    http://gcc.gnu.org/java/faq.html#5_2

I quote:
------------------------------- 8< -------------------------------
5.2 When I run the debugger I get a SEGV in the GC! What's going on?

    This is "normal"; the Garbage Collector (GC) uses it to determine 
stack boundaries. It is ordinarily caught and handled by the GC -- you 
can see this in the debugger by using cont to continue to the "real" 
segv. 
------------------------------- 8< -------------------------------

BTW, Dara's compilation error was simply because the shell tries
to expand the "$1" in Test$1.class on the command line and expands
it to the empty string since the variable "1" is not defined.
Comment 20 oyvind.harboe 2003-08-21 07:20:58 UTC
>FWIW, the test program does not crash for me even after repeated
>attempts. I am using GCC 3.4 snapshot for Win32 dated 20030802 as 
>available on Mohan's GCJ site: http://www.thisiscool.com/gcc_mingw.htm
>(This snapshot has Boehm-GC 6.3 alpha 1.)

Arrgghh.... :-)

Note that it *is* very hard to reproduce. 

Would it be helpful if I set up a VNC server on a Windows machine and provided 
access?

Also, look out for other manifistations of the problem(see end for example).

>I would also like to point out that getting a SEGV in the GC
>while running inside a debugger is common and expected as
>noted in this GCJ FAQ entry:
>
>    http://gcc.gnu.org/java/faq.html#5_2
>
>I quote:
>------------------------------- 8< -------------------------------
>5.2 When I run the debugger I get a SEGV in the GC! What's going on?
>
>    This is "normal"; the Garbage Collector (GC) uses it to determine 
>stack boundaries. It is ordinarily caught and handled by the GC -- you 
>can see this in the debugger by using cont to continue to the "real" 
>segv. 
>------------------------------- 8< -------------------------------

This is not the case that I've found. "cont" does not work from the debugger. 
Presumably one should be on the lookout for this so as not to get confused 
though. I'll attach a picture from the debug session...

Another manifistation of the problem:

When running this session from the debugger, then debugger didn't stop....

second thread 5685000 bbbabaffdd
second thread 5686000 ccfaag
second thread 5687000 dddbbdag
second thread 5688000 aaeaadddf
first thread 3178000          cecgb
first thread 3179000          ffccgcd
second thread 5689000 gfeaeae
second thread 5690000 fffdgcg
second thread 5691000 eeeaca
second thread 5692000 eeeacd
second thread 5693000 ebababa
second thread 5694000 dggfage
second thread 5695000 ggfe
second thread 5696000 cccadda
second thread 5697000 eefgca
second thread 5698000 bbdcdceaa
second thread 5699000 gggcdf
Exception in thread "main" second thread 5700000 ffffffaeb
second thread 5701000 dfffdcdf
second thread 5702000 cccccbff
second thread 5703000 gdcg
second thread 5704000 fggg
second thread 5705000 ecbcc
second thread 5706000 cfbcedd
second thread 5707000 ggfgcff
second thread 5708000 ccddcee
second thread 5709000 cccdcdd
second thread 5710000 eaebcc
second thread 5711000 feffegcffd
second thread 5712000 adadgeeb
second thread 5713000 ddcgddca
second thread 5714000 ccdae
second thread 5715000 ggfagcc
second thread 5716000 bbbbbbfd
second thread 5717000 ccccccdad
second thread 5718000 cacacaabbba
second thread 5719000 cccdcbg
second thread 5720000 cgabff
second thread 5721000 ggddf
second thread 5722000 gdadgcb
second thread 5723000 cabd
second thread 5724000 aaacgaa
second thread 5725000 gffgfcb
second thread 5726000 fffffef
second thread 5727000 cgcbcff
second thread 5728000 gcgcgd
second thread 5729000 gbabda
second thread 5730000 bbbcbgcb
second thread 5731000 bddcag
second thread 5732000 ccccbcceb
second thread 5733000 bbacd
second thread 5734000 aaaddaacacadbgcad
second thread 5735000 fedgfc
second thread 5736000 efcfa
second thread 5737000 ggacaadc
second thread 5738000 gggggggfefcc
second thread 5739000 eedbaaafbdc
second thread 5740000 eabdffd
second thread 5741000 gdfgfdgcagdc
second thread 5742000 eeecgeead
second thread 5743000 dedgega
second thread 5744000 ffeeba
second thread 5745000 dedcdcfda
second thread 5746000 acacaea
second thread 5747000 eeeefaea
java.lang.ArrayStoreException
   at Test.replaceAll(java.lang.String, java.lang.String, java.lang.String) (C:\
cygwin\home\oharboe\Test.java:17)
   at Test.stressGB(java.lang.String) (C:\cygwin\home\oharboe\Test.java:63)
   at Test.main(java.lang.String[]) (C:\cygwin\home\oharboe\Test.java:39)
second thread 5748000 eedadeg
second thread 5749000 bbadfc
second thread 5750000 cagg
second thread 5751000 bbbfgbfe
second thread 5752000 dgfege
second thread 5753000 bbbbbbcd
second thread 5754000 ccc

Comment 21 Mohan Embar 2003-09-01 23:03:31 UTC
On my machine, I got a NullPointerException. After commenting out the unhandled exception handler in win32.cc and the SIGSEGV handler in prims.cc, I got the following backtrace:

#0  0x00412759 in java::lang::Object::getClass() (this=0x1c63fd8)
    at /datal/gcc/gcc/libjava/java/lang/natObject.cc:56
#1  0x0040145e in Test.replaceAll(java.lang.String, java.lang.String, java.lang.String) (in=0x1c65000, a=0x1c11fd8, b=0x175efd8) at Test.java:11
#2  0x00401bcd in Test.stressGB(java.lang.String) (thread=0x175b990)
    at Test.java:63
#3  0x0040173d in Test.main(java.lang.String[]) (args=0x1756fe0)
    at Test.java:39
#4  0x00416e62 in gnu.gcj.runtime.FirstThread.run() (this=0x17befc0)
    at /datal/gcc/gcc/libjava/gnu/gcj/runtime/FirstThread.java:54
#5  0x0041f827 in _Jv_ThreadRun(java::lang::Thread*) (thread=0x17befc0)
    at /datal/gcc/gcc/libjava/java/lang/natThread.cc:285
#6  0x0040432f in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) (klass=0x5a6210, name=<incomplete type>, argc=1, argv=0x3d4088, 
    is_jar=false) at /datal/gcc/gcc/libjava/prims.cc:1004
#7  0x004043ff in JvRunMain (klass=0x5a6210, argc=1, argv=0x3d4088)
    at /datal/gcc/gcc/libjava/prims.cc:1014
#8  0x004012e2 in main (argc=1, argv=0x3d4088)
    at D:/DOCUME~1/MOHANE~1/LOCALS~1/Temp/ccgfcaaa.i:0
Comment 22 hans_boehm 2003-09-03 21:48:42 UTC
Subject: RE:  [3.3/3.4 regression] [win32] garbage colle
	ction crash in GCJ

Unfortunately, I'm not very familiar with mingw32.

I would assume that the real problem is occasional premature collection of an object.
It would be nice to verify that by debugging one of the crashes enough to convince
yourself that the crash is caused by an object that has been reclaimed.  Reclaimed
objects will normally be cleared except for the first word which is used as a link,
or they may have been reused for a different purpose.  Retrieving the class or anything
else by indirecting through the vtable may well generate a segmentation fault.

If p is the suspicious object, it would be nice to print

*GC_find_header(p), GC_is_marked(p), GC_gc_no

as well as the contents of p from the debugger.  If p doesn't look anything like the
intended type, GC_is_marked(p) is zero, and the header indicates the block was reclaimed
in this GC cycle, I would assume it was prematurely collected.

If premature collection is indeed the problem, there are a number of possible causes:

1) A generic collector bug.  (Seems unlikely, since it's apparently Windows specific.)

2) Bad root information for the platform, e.g. the collector doesn't quite see all the
thread stacks correctly.

3) Bad gcj generated collector information in the vtable.

4) A bug in the gcj-specific mark routines.

5) Some clever gcc optimization that hid a pointer from the GC.  (This is very unlikely,
since this is unoptimized.  But we might still be missing a register from the root set.
Is the problem more frequent with optimized code?)

It should be possible to mostly exclude (2) and certain collector bugs by setting the
environment variable GC_IGNORE_GCJ_INFO and checking whether the problem is still
reproducible.  (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.)

It would also be interesting to know if the collector does better if you build it with
USE_GENERIC_PUSH_REGS.  That should work well with gcc, and bypasses the current code
to identify relevant registers.

If that doesn't give much information, it would be really nice to get a test case that
fails after a predictable number of collections on a predictable object p.  If you get
to that stage, the procedure is to set a break point in GC_finish_collection(), and call
GC_is_marker() on every object in the reference chain that's used to reach p.  That
should identify which pointer isn't being followed by the collector.

If that's not possible, it would be good to learn as much as possible about the objects
that get collected too early, and how they can be reached from the stack.  Are they
usually directly pointed to by a stack-allocated variable?

Hans


Comment 23 oyvind.harboe 2003-09-08 10:48:37 UTC
Created attachment 4716 [details]
Snapshot of debug session for a different manifistation

In my fearless pursuit of things I know nothing about, I saw a different
manifistation of a crash with the same program. Compiled with GCJ 3.4.

Attaching on the offchance that it might give some insight into what is going
on.

Øyvind
Comment 24 oyvind.harboe 2003-09-08 11:15:36 UTC
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

Comment 25 hans_boehm 2003-09-09 00:03:34 UTC
Subject: RE:  [3.3/3.4 regression] [win32] garbage colle
	ction crash in GCJ

I read the screen dump as saying that this died in _Jv_NewString because
it found that the object returned by _Jv_AllocString had (presumably)
both a zero data and zero boffset field.  Thus it was trying to copy
characters to a zero target address.

This is strange since _Jv_AllocString sets both of these fields to
nonzero values just before this.

It would be nice to get similar information like this for one or two more
crashes.  You could get somewhat better information by:

1) Building the collector with debug info, so that *GC_find_header(p)
prints a structure.  Failing that, it would be good to see the 50 or so
words following the value returned by GC_find_header.

2) Printing the contents of the heap object which appears to have been
clobbered with something like "x/10wx".

3) The value of GC_gc_no.  This is not a function.

4) The value of GC_arrays._words_allocd.  This probably requires debug info.

I assume this is reproducible on a uniprocessor without "hyperthreading"?

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.

Hans
> 
Comment 26 oyvind.harboe 2003-09-09 07:04:41 UTC
(My previous GCC build machine committed sucide after a power outage, and I 
haven't put together a new one yet).


Would it be any help if this was reproducable w/WINE under Linux?

>I read the screen dump as saying that this died in _Jv_NewString because
>it found that the object returned by _Jv_AllocString had (presumably)
>both a zero data and zero boffset field.  Thus it was trying to copy
>characters to a zero target address.
>
>This is strange since _Jv_AllocString sets both of these fields to
>nonzero values just before this.

I've only seen this once the AllocString problem once, but I'll be on the 
lookout.

>I assume this is reproducible on a uniprocessor without "hyperthreading"?

Yes. At least three single CPU machines: AMD 1800, Pentium III 400, AMD 800.

>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...


C:\Temp\foo>\thisiscool-gcc-3.4\gcc-3.4\bin\gcj -g --main=Test Test.java -o test


C:\Temp\foo>dir
 Volume in drive C has no label.
 Volume Serial Number is 405F-43D6

 Directory of C:\Temp\foo

09.09.2003  09:03       <DIR>          .
09.09.2003  09:03       <DIR>          ..
09.09.2003  09:03            3 804 032 test.exe
08.09.2003  13:28                  784 Test.java
               2 File(s)      3 804 816 bytes
               2 Dir(s)  60 380 672 000 bytes free

C:\Temp\foo> set GC_PRINT_STATS=1

C:\Temp\foo>test
first thread 0
second thread 0
second thread 100000
first thread 100000
second thread 200000
first thread 200000
second thread 300000
first thread 300000
second thread 400000
second thread 500000
^C
C:\Temp\foo>dir
 Volume in drive C has no label.
 Volume Serial Number is 405F-43D6

 Directory of C:\Temp\foo

09.09.2003  09:03       <DIR>          .
09.09.2003  09:03       <DIR>          ..
09.09.2003  09:03            3 804 032 test.exe
08.09.2003  13:28                  784 Test.java
               2 File(s)      3 804 816 bytes
               2 Dir(s)  60 380 672 000 bytes free

C:\Temp\foo>




Comment 27 hans_boehm 2003-09-09 18:25:05 UTC
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 
Comment 28 oyvind.harboe 2003-09-10 06:53:00 UTC
>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.)
>...

Sure! I'll put it together and attach it to this bugreport.

CygWin GDB works great!

>> 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.

Also, this happens on Mohans machine, but I don't know what he's running.

Pretty pervasive problem(if tricky to reproduce).

Øyvind
Comment 29 oyvind.harboe 2003-09-10 07:28:33 UTC
Created attachment 4732 [details]
Trying to upload a static compiled version of the test program with debug info

Due to the bugzilla limit of 1Mb, I have to split this file into two.

Arrggh....
Comment 30 oyvind.harboe 2003-09-10 07:31:11 UTC
Created attachment 4733 [details]
Part two of the file

This is part two.

To extract issue the following commands from CygWin:

cat staticaa  staticab >static.tar.bz2
tar -j -xvf static.tar.bz2


To debug use the CygWin Insight debugger. Note the crash happens much more
easily with insight.exe than from gdb.exe(no idea why this is, but it is a
useful hint).

Øyvind
Comment 31 Hans Boehm 2003-09-15 23:59:27 UTC
Created attachment 4764 [details]
Annotated debugging log based on Oyvind's executable

I will submit an untested patch shortly.  In case that doesn't do the trick,
here are debug logs from 3 crashes which should help with any further
debugging.
Comment 32 Hans Boehm 2003-09-16 00:15:03 UTC
Created attachment 4765 [details]
Proposed patch

GC_generic_push_regs was carefully pushing all relevant registers on the stack
with __builtin_unwind_init, and then calling a routine to scan the stack for
pointers.  Unfortunately the latter was compiled as a tail call, and thus the
frame containing the registers was popped before the stack was scanned.

With the old GC build infrastructure, mach_dep.c was not optimized to avoid
issues like this.  That may still be a good idea.  This patch instead convinces
gcc that the critical call is not in tail position, and thus the frame can't be
prematurely removed.

Since I can't rebuild the runtime that exhibited this problem, someone else
will have to do the real testing.  I can't demonstrate that this was really the
cause of the observed problem, and it may not have been.  Gcc does seem to
build with the patch, and the generated code for GC_generic_push_regs now looks
OK to me.  (And the standalone gctest works on Linux, as it did before.)

A patch along these lines should almost certainly be checked in, even if this
doesn't fix the problem at hand.
Comment 33 oyvind.harboe 2003-09-16 07:20:41 UTC
>I can't demonstrate that this was really the cause of the observed 
>problem, and it may not have been.  Gcc does seem to build with the 
>patch, and the generated code for GC_generic_push_regs now looks
>OK to me.  (And the standalone gctest works on Linux, as it did before.)

I'm in the process of testing the patch, but one thing that isn't entirely 
clear to me:

Why doesn't this problem manifest itself under Linux?

Øyvind

Comment 34 hans_boehm 2003-09-16 18:03:43 UTC
Subject: RE:  [3.3/3.4 regression] [win32] garbage colle
	ction crash in GCJ

My guess is that it eventually would.

Basically callee-save (preserved) registers are not being scanned by the
collector in the thread that initiates the collection.  But very often,
especially on X86, they will accidentally get scanned anyway, since they
happen to be saved by some GC routine between the client code and the
stack marking code.  Thus I would have expected this bug to rarely manifest
itself on X86, which has so few registers that spills to the stack are
very common.  It turns this doesn't show up on a number of other platforms
either, because they often use other methods for doing this, or don't optimize
mach_dep.c.

If this is actually the cause of the observed bug, then there is apparently
one rarely executed path through the GC code on mingw32 on which one of the
preserved registers is not saved.  The Linux code is sufficiently different
that such a path might not exist.  (For example, thread-local allocation
is enabled on Linux, so that the allocation path looks very different.)
But this doesn't prevent some future version of gcc from 
breaking it on Linux, too.

Yet another example of why I tend to trust multi-platform code more than
single-platform code ...

> -----Original Message-----
> From: oyvind dot harboe at zylin dot com
> 
> Why doesn't this problem manifest itself under Linux?
> 
> Øyvind
> 
Comment 35 oyvind.harboe 2003-09-17 07:13:03 UTC
>A patch along these lines should almost certainly be checked in, even if 
>this doesn't fix the problem at hand

I've recompiled and tested now, and it appears the problem is still there, same 
symptoms have not changed(segmentation fault in getClass).

Øyvind
Comment 36 Hans Boehm 2003-09-17 17:14:53 UTC
Subject: Re:  [3.3/3.4 regression] [win32] garbage collection
 crash in GCJ

Oyvind -

Could you replace the static executable attached to the bug with
the new version?

It would also be very helpful if you could rebuild libgcj with debug
information for boehm-gc, and with the getenv stuff enabled.

Thanks.

Hans


Comment 37 Hans Boehm 2003-09-19 01:16:14 UTC
Created attachment 4783 [details]
Another annotated debugging log

This short debug log was obtained with the library I built on Oyvind's machine.

It shows pretty clearly that the GC doesn't know about the thread that's
failing, i.e. it's not in thread_table (win32_threads.c).  Thus its stack is
apparently not scanned at all.	Oops.

This problem is likely to be specific to static linking on win32 with gcj,
though the collector interface should make it easier (or possible) to get this
right.

Since we are not using DllMain for notifying the GC of new threads, it needs to
be explicitly notified of all threads, including the main one.	The work that's
currently done in GC_CreateThread or threadAttach needs to be done for the main
thread as well.

On Oyvind's machine, I built (and did "make install") of a libgcj that
explicitly checks that it finds the current thread as its scanning threads in a
collection.  I haven't yet had a chance to run it to verify that it fails as
expected.  That test is sufficiently cheap that it should probably always be
on.

I may not get a chance to do much on this for the next three days.  If my
conjecture is completely correct, the test should succeed if all the work is
done outside the main thread, i.e. if the main thread just waits.  If someone
has time, it would be good to check that.
Comment 38 Hans Boehm 2003-10-03 21:49:38 UTC
Created attachment 4888 [details]
Combined patch

Based on Oyvind's and my testing, this appears to fix the problem.  I don't
know of any remaining garbage collection issues with Mingw32 or Cygwin.

This includes the earlier patch, fixes an apparent Cygwin memory leak, and
generally cleans up the win32 thread support code in the collector.
Comment 39 oyvind.harboe 2003-10-04 09:46:32 UTC
>Combined patch
>
>Based on Oyvind's and my testing, this appears to fix the problem.  I don't
>know of any remaining garbage collection issues with Mingw32 or Cygwin.
>
>This includes the earlier patch, fixes an apparent Cygwin memory leak, and
>generally cleans up the win32 thread support code in the collector.

Should this be applied to the GCC 3.3 branch as well?

Øyvind
Comment 40 hans_boehm 2003-10-04 18:35:32 UTC
Subject: RE:  [3.3/3.4 regression] [win32] garbage colle
	ction crash in GCJ

I believe it's needed for 3.3 to work correctly in win32.  It may need some
minor work to correctly merge it there.  I would omit the configure.in
and gc_priv.h changes in 3.3, since they constitute a feature enhancement
(admittedly to support debugging), not a bug fix per se.  The same applies
to the added assertion in misc.c, but not the GC_thr_init() call.

It would  be better to use win32_threads.c as is.  It includes some code
cleanup which is not strictly a bug fix.  But that was included because the
cleaned-up code was easier to fix, and more likely to be correct.

If someone could check that this applies correctly and works with the current 3.3
tree, and then checks it in, that would be great.

(Oyvind - I'm not sure exactly what version you had on your machine.  I did
have to make some minor adjustments there, but things seemed to work fine.)

Hans

> -----Original Message-----
> From: oyvind dot harboe at zylin dot com
> Should this be applied to the GCC 3.3 branch as well?
> 
> Øyvind
> 
Comment 41 oyvind.harboe 2003-10-05 10:28:33 UTC
>(Oyvind - I'm not sure exactly what version you had on your machine.  I did
>have to make some minor adjustments there, but things seemed to work fine.)

It is a GCC 3.4 du jour from around the time when you first got access to the
account.

Øyvind


Comment 42 Andrew Pinski 2003-10-06 06:15:53 UTC
Only a 3.3 regression right now but it looks like it is not going to be fixed for 3.3.2, lets try for 
3.3.3 unless someone can backpoint the patch.
Comment 43 Jeff Sturm 2003-10-06 12:16:33 UTC
Reported fixed by http://gcc.gnu.org/ml/java-patches/2003-q4/msg00024.html
Comment 44 oyvind.harboe 2003-10-11 10:51:26 UTC
*** Bug 10748 has been marked as a duplicate of this bug. ***