Re: GCJ 4.03 crash on Windows 98 continued

[Marco Trudel <mtrudel at gmx dot ch>]

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