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

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

[pinskia@physics.uc.edu]

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


pinskia@physics.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.3.1

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

[mmitchel 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 mmitchel at gcc dot gnu dot org  2003-07-20 01:19 -------
What is the current status of this bug?

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

[oyvind dot harboe at zylin dot com]

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-07-21 06:56 -------
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)

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

[oyvind dot harboe at zylin dot com]

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-07-21 06:59 -------
Forgot an important bit, which thread caused the exception...


Program received signal SIGSEGV, Segmentation fault.
0x0045eae3 in GC_mark_from ()

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

[oyvind dot harboe at zylin dot com]

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-07-21 07:12 -------
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)

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

[oyvind dot harboe at zylin dot com]

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


oyvind dot harboe at zylin dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hans_boehm at hp dot com


------- Additional Comments From oyvind dot harboe at zylin dot com  2003-07-23 21:06 -------
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

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

[mmitchel 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


mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.3.1                       |3.3.2


------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-07-23 23:38 -------
Win32 is not a primary evaluation platform.

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

[oyvind dot harboe at zylin dot com]

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-07-24 09:02 -------
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(), "");
		}
	}
}

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

[pinskia at physics dot uc dot edu]

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


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.3 regression] [win32]    |[3.3/3.4 regression] [win32]
                   |garbage collection crash in |garbage collection crash in
                   |GCJ                         |GCJ


------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-24 11:19 -------
Also happens in 3.4 from bug 11656.

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

[pinskia at physics dot uc dot edu]

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 pinskia at physics dot uc dot edu  2003-07-24 11:20 -------
*** Bug 11656 has been marked as a duplicate of this bug. ***

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

[oyvind dot harboe at zylin dot com]

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-07-25 11:47 -------
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)

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

[oyvind dot harboe at zylin dot com]

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-08-04 10:58 -------
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)

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

[oyvind dot harboe at zylin dot com]

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-08-15 09:50 -------
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)

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

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-08-20 06:36 -------
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

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

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-08-20 08:05 -------
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

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

[rmathew at hotmail dot com]

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 rmathew at hotmail dot com  2003-08-21 06:16 -------
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.

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

[oyvind dot harboe at zylin dot com]

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


oyvind dot harboe at zylin dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rmathew at hotmail dot com


------- Additional Comments From oyvind dot harboe at zylin dot com  2003-08-21 07:20 -------
>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

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

[membar 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 membar at gcc dot gnu dot org  2003-09-01 23:03 -------
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

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

[hans_boehm at hp dot com]

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-03 21:48 -------
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

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

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

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

[hans_boehm at hp dot com]

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 00:03 -------
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
>

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]

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-09 07:04 -------
(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>

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

[hans_boehm at hp dot com]

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

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

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-10 06:53 -------
>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

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

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-16 07:20 -------
>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

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

[hans_boehm at hp dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

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-16 18:03 -------
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
>

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

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-17 07:13 -------
>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

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

[Hans dot Boehm at hp dot com]

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 dot Boehm at hp dot com  2003-09-17 17:14 -------
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

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

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-10-04 09:46 -------
>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

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

[hans_boehm at hp dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

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-10-04 18:35 -------
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
>

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

[oyvind dot harboe at zylin dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

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-10-05 10:28 -------
>(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

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

[pinskia 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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.3/3.4 regression] [win32]|[3.3 regression] [win32]
                   |garbage collection crash in |garbage collection crash in
                   |GCJ                         |GCJ
   Target Milestone|3.3.2                       |3.3.3


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-10-06 06:15 -------
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.

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

[jsturm 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


jsturm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


------- Additional Comments From jsturm at gcc dot gnu dot org  2003-10-06 12:16 -------
Reported fixed by http://gcc.gnu.org/ml/java-patches/2003-q4/msg00024.html

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

[oyvind dot harboe at zylin dot com]

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-10-11 10:51 -------
*** Bug 10748 has been marked as a duplicate of this bug. ***