GCJ 3.3 crash with string handling reproduceable case

[Boehm, Hans]

Unfortunately, I'm unfamiliar with MingW, and I'm having trouble parsing some of this.

The warnings don't look familiar to me.  Does anyone know what's generating them?

The stack frame in GC_register_dynamic_libraries (dyn_load.c) corresponds to code that is walking the process address space with VirtualQuery to find root segments.  Based on (distant) past experience, VirtualQuery is bug-prone.  (It was broken in win32S, for example.)  If this is doing anything other than just calling the underlying win32 routine, I would look there carefully.

I wasn't able to deduce from the stack trace exactly what generated the bad reference or bad system call.  If someone can read it well enough to deduce that, please enlighten me ...

Hans

> -----Original Message-----
> From: Ranjit Mathew [mailto:rmathew@hotmail.com]
> Sent: Wednesday, February 26, 2003 6:08 AM
> To: aph@redhat.com
> Cc: java@gcc.gnu.org
> Subject: Re: GCJ 3.3 crash with string handling reproduceable case
> 
> 
> >Ranjit Mathew writes:
> >  >
> >  > BTW, as Jeff had pointed out earlier, the "gctest" from the GC
> >  > always crashes immediately for me as well with a GPF.
> >
> >Well, that's the thing to fix first, before doing _anything_ 
> with gcj.
> >If the gc isn't reliable, nothing is reliable.
> >
> >Andrew.
> 
> :-( Yes, it isn't encouraging at all, is it? Especially when
> GCJ/Win32 *seems* to work otherwise...
> 
> I just downloaded Boehm GC 6.1 from:
> 
>    http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/
> 
> and was easily able to compile it with MSYS/MinGW, including
> the gctest application. Sure enough, gctest crashes on me
> (consistently) and here's what DrMinGW (always) tells me:
> ------------------------------- 8< ----------------------------------
> gctest.exe caused an Access Violation at location 77f85c41 in module 
> ntdll.dll Writing to location 00000010.
> 
> Registers:
> eax=00000000 ebx=00000000 ecx=0041e0d0 edx=00000050 esi=0041e0c0 
> edi=00000000
> eip=77f85c41 esp=0022fe30 ebp=0022fe90 iopl=0         nv up 
> ei pl zr na po 
> nc
> cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             
> efl=00000246
> 
> Call stack:
> 77F85C41  ntdll.dll:77F85C41  RtlReAllocateHeap
> 77F85BD1  ntdll.dll:77F85BD1  RtlReAllocateHeap
> 00403362  gctest.exe:00403362  WinMain  test.c:1618
> int WinMain(
> 	HINSTANCE instance = &{
> 		int i = 9460301
> 	},
> 	HINSTANCE prev = &{
> 		int i =
> 	},
> 	LPSTR cmd = &0,
> 	int n = 10
> )
> 	...
> 	# endif
> 	# if NTEST > 0
> >	   for (i = 0; i < NTEST; i++) {
> 	    h[i] = GC_CreateThread(NULL, 0, thr_run_one_test, 
> 0, 0, &thread_id);
> 	    if (h[i] == (HANDLE)NULL) {
> 	...
> 
> 00411573  gctest.exe:00411573  GC_register_dynamic_libraries  
> dyn_load.c:837
> void GC_register_dynamic_libraries(
> 
> )
> 	...
> 	    base = p;
> 	}
> >	limit = new_limit;
> 	    }
> 	}
> 	...
> 
> 0040116B  gctest.exe:0040116B
> 00401013  gctest.exe:00401013
> 77EA847C  KERNEL32.dll:77EA847C  DebugBreak
> ------------------------------- 8< ----------------------------------
> 
> The standard output of gctest shows lots of lines like:
> ------------------------------- 8< ----------------------------------
> Warning: changing type size from 8 to 64
> Warning: changing type size from 8 to 64
> Warning: changing type size from 2 to 16
> Warning: changing type size from 2 to 16
> Warning: changing type size from 1 to 8
> Warning: changing type size from 1 to 8
> Warning: changing type size from 8 to 64
> Warning: changing type size from 8 to 64
> Warning: changing type size from 2 to 16
> Warning: changing type size from 2 to 16
> ...
> ------------------------------- 8< ----------------------------------
> 
> Ranjit.
> 
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE* 
> http://join.msn.com/?page=features/virus
>