GCJ 4.03 crash on Windows 98 continued

[Marco Trudel]

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