GCJ 4.03 crash on Windows 98 continued

Marco Trudel mtrudel@gmx.ch
Mon Jun 19 21:27:00 GMT 2006


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


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /