RE: GCJ 4.03 crash on Windows 98 continued

["Boehm, Hans" <hans dot boehm at hp dot com>]

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