[Gc] Status of gc on Mac OS X running on intel proc ?

Renaud Blanch renaud.blanch at imag.fr
Fri Sep 29 06:01:31 PDT 2006

Le 28 sept. 06 à 23:02, Boehm, Hans a écrit :

> Thanks.  It looks like there are two issues here:
> 1) Thread_get_state usually fails in gctest.  The calling code is at
> around line 100 in darwin_stop_world.c.  It would be good to see if  
> you
> can get more information from the return code or anything else to  
> figure
> out why this is happening.  I think this is the most serious problem.

I have investigated this issue.
thread_get_state returns KERN_INVALID_ARGUMENT.
It seems related to the usage of the generic MACHINE_THREAD_STATE*  
When replaced with specific i386_THREAD_STATE* constant, every thing  
works on my machine (configured with --enable-threads=posix).
You will find below a patch that replace MACHINE_* with PPC_* or  
i386_ constants according to he POWERPC or I386 defines.
I don't understand why MACHINE_* constants are not defined properly  
(is it related to my system, a bug in Apple headers, or a problem  
with configure), but the patch does the work and should work with PPC  
architecture (not tested).

The patch also comments a call to GC_printf3 which was done when  
DEBUG_THREADS is set, but this function does not seem to exist in the  
gc7.0alpha7 distribution.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: darwin_stop_world.patch
Type: application/octet-stream
Size: 1590 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20060929/5fcfa8b4/darwin_stop_world.obj
-------------- next part --------------

> 2) It looks like test_cpp is invoking the system free when it  
> shouldn't.
> The next step here would be to look at the stack trace when the error
> message is printed to see where the free call is coming from.  This
> looks like a problem that's specific to the gc_cpp.h C++ interface,
> probably related to replacing ::new and friends.

Provided the patch above, make check reports "All 5 tests passed"  
when configured with --enable-threads=posix and --enable-cplusplus.
However, there is still a bunch of line like this in the output :
test_cpp(23980) malloc: ***  Deallocation of a pointer not malloced:  
0x4640f8; This could be a double free(), or free() called with the  
middle of an allocated block; Try setting environment variable  
MallocHelp to see tools to help debug

I will investigate this further.

> It looks like single-threaded C applications probably work, at  
> least if
> you build without thread support.
Yes, everything works out of the box when configured without thread  


> Hans
>> -----Original Message-----
>> From: gc-bounces at napali.hpl.hp.com
>> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Renaud Blanch
>> Sent: Thursday, September 28, 2006 12:22 AM
>> To: gc at napali.hpl.hp.com
>> Subject: [Gc] Status of gc on Mac OS X running on intel proc ?
>> Hello,
>> I was successfully using gc6.8 on a PPC PowerBook and on a
>> dual G5 Mac running Mac OS X version 10.4.
>> I switched to an Intel dual core MacBook Pro a few weeks ago.
>> Basic make check reports failures on Mac OS X while it works
>> fine on the same machine running linux (ubuntu with a SMP kernel).
>> Has anybody reported similar problems or conversely reported
>> success in using the gc on intel (dual core) based machine
>> running Mac OS X ?
>> Thanks.
>> In case it helps, you will find below the configure and make
>> check logs for gc6.8 & gc7.0alpha7 for both linux & Mac OS X runs.
>> I will happily collaborate with people motivated to provide
>> patch to the gc in order to make it work for intel macs.
>> If some body can point me in the right direction, and give me
>> some hints, I am also motivated to contribute !
>> regards,
>> Renaud

Renaud Blanch
mailto:renaud.blanch at imag.fr

More information about the Gc mailing list