GCJ 4.03 crash on Windows 98 continued

[Jesper Juul / Soup Games]

It works great on win 98 now!

I would like to thank all of you for your generous efforts!

-Jesper


At 20-06-2006 11:16, Marco Trudel wrote:
>Ranjit already made a backport (thank you Ranjit) which I adapted 
>for the 4.1.1...
>
>regards
>Marco
>
>
>Marco Trudel wrote:
>>Hello Hans
>>If you create a patch for gcc4.1.1, I'll be happy to test if it 
>>works on Windows 98... I assume this would be extra work for you, 
>>but it would be great if you could do it...
>>regards
>>Marco
>>
>>Boehm, Hans wrote:
>>>Gc6.7 in fact contains the suggested fix.  It explicitly distinguishes
>>>Windows NT descendants from ME and predecessors, and checks against
>>>MEM_PRIVATE for the latter.  It would be good to confirm that that
>>>solves the problem.
>>>
>>>Hans
>>>>-----Original Message-----
>>>>From: Ranjit Mathew [mailto:rmathew@gmail.com] Sent: Monday, June 
>>>>19, 2006 11:38 AM
>>>>To: Jesper Juul / Soup Games
>>>>Cc: java@gcc.gnu.org; Boehm, Hans
>>>>Subject: Re: GCJ 4.03 crash on Windows 98 continued
>>>>
>>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>>Hash: SHA1
>>>>
>>>>Jesper Juul / Soup Games wrote:
>>>>>For the record, I have gotten a bit deeper on the issue of why 
>>>>>gcj 4.0x executables crash on Windows 98.
>>>>In my limited testing, I have also found that  even the simplest 
>>>>executables produced by GCJ to crash under Windows 98. It seems 
>>>>to be a problem in the GC. One of the workarounds is to set the 
>>>>environment variable GC_DONT_GC to disable the GC entirely.
>>>>
>>>>Another workaround is to take a hint from:
>>>>
>>>>http://blog.gmane.org/gmane.comp.programming.garbage-collectio
>>>>n.boehmgc/day=20051129
>>>>
>>>>and apply something like the following patch:
>>>>- ------------------------------- 8< -------------------------------
>>>>Index: dyn_load.c
>>>>===================================================================
>>>>- --- dyn_load.c  (revision 114756)
>>>>+++ dyn_load.c  (working copy)
>>>>@@ -901,7 +901,8 @@ void GC_register_dynamic_libraries()
>>>>                  * !is_frame_buffer(p, buf.RegionSize, buf.Type)
>>>>                  * instead of just checking for MEM_IMAGE.
>>>>                  * If something breaks, change it back. */
>>>>- -               && buf.Type == MEM_IMAGE) {
>>>>+               /* && buf.Type == MEM_IMAGE) {   */
>>>>+               && !is_frame_buffer(p, buf.RegionSize, buf.Type)) {
>>>>  #              ifdef DEBUG_VIRTUALQUERY
>>>>                   GC_dump_meminfo(&buf);
>>>>  #              endif
>>>>- ------------------------------- 8< -------------------------------
>>>>
>>>>To quote Hans:
>>>>"It sounds like the right solution here is to check is to 
>>>>explicitly check for ME and predecessors, and to allow 
>>>>MEM_PRIVATE there, but to continue to insist on MEM_IMAGE for 
>>>>newer msft operating systems."
>>>>
>>>>HTH,
>>>>Ranjit.
>>>>
>>>>- --
>>>>Ranjit Mathew       Email: rmathew AT gmail DOT com
>>>>
>>>>Bangalore, INDIA.     Web: http://rmathew.com/
>>>>
>>>>
>>>>
>>>>
>>>>-----BEGIN PGP SIGNATURE-----
>>>>Version: GnuPG v1.4.2 (GNU/Linux)
>>>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>>
>>>>iD8DBQFElu8aYb1hx2wRS48RAmTBAKCfwcjRLkDoujST8y0ewr2d2hAQjQCfaVEv
>>>>UsCG+PaK74Ip/I7QweXM3wA=
>>>>=4FV1
>>>>-----END PGP SIGNATURE-----
>>>