[Gc] frame buffer recognition / windows ME

Boehm, Hans hans.boehm at hp.com
Tue Nov 29 12:04:13 PST 2005


Based on other reports, data segments are mapped as MEM_IMAGE
(http://thread.gmane.org/gmane.comp.gcc.java.devel/10435), presumably
under XP.

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.  Does
anyone know of a reason that wouldn't work?  I know there have been
other issues along these lines ...

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of grischka
> Sent: Tuesday, November 29, 2005 11:03 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] frame buffer recognition / windows ME
> 
> 
> >From REAME.changes - Since 6.3:
>  - Removed GC_IGNORE_FB frame buffer recognition, and replaced
>    it with a check that the mapping type is MEM_IMAGE.
>    In theory, this should work much better, but it is a high
>    risk change for win32....  
>  
> dyn_load.c: GC_register_dynamic_libraries
> && buf.Type == MEM_IMAGE) {  
> 
> This seems to break on windows ME. I found that VirtualQuery returned 
> always MEM_PRIVATE. in buf.Type for data mem. Accordingly gctest 
> was crashing reliably as no data pages were added to the roots set. 
> (Or was it meant as ... && buf.Type != MEM_IMAGE ? Did not test on 
> win2k/xp)
> 
> Regards
> --- grischka
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list