OSX Tiger/G4 Bus error

[Brian Rice]

Hi Nick,

That does look like the error I was getting when it failed for me.  
Now that I've tried your example, I see that I can reproduce it on my  
G4 iBook but not on the G5, which is interesting. Maybe that helps?  
I'll try looking around in gdb for an answer.

In any case, the specific sources of the top stack frame elements  
don't look suspect. I'll start digging. Lee, got any ideas?

On Aug 26, 2005, at 4:41 AM, Nick Forde wrote:

> Hmm. I don't see this problem if I compile without -DNDEBUG=1.
>
> Nick.
>
> On 26 Aug 2005, at 10:03, Nick Forde wrote:
>
>> Using GCC 4.0 on OS X Tiger/G4 I'm getting bus errors when  
>> bootstrapping.
>> I haven't tracked this down yet but append below some debugger output
>> in case anyone else can help.
>>
>> (gdb) run big.image
>> Starting program: /Users/nickf/Home/prj/slate/main/vm big.image
>> Reading symbols for shared libraries . done
>> Bootstrapping libraries... (this may take a while. Save the image  
>> when done).
>> Slate: Growing heap to 4821488 bytes.
>> Loading 'src/mobius/syntax/quote.slate'
>> Loading 'src/mobius/syntax/cascade.slate'
>> Loading 'src/lib/macro.slate'
>> Loading 'src/lib/numericMixin.slate'
>> Loading 'src/lib/tuple.slate'
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x49c5c318
>> 0x00005c94 in PSRoleTable_hashEntryForInsertingName_  
>> (roles=0x20ec8b4, name=1237697304) at vm.c:2348
>> 2348      hash = ((ObjectPointer_pointer(name)) -> header).idHash  
>> & (tableSize - 1);
>>
>> (gdb) where
>> #0  0x00005c94 in PSRoleTable_hashEntryForInsertingName_  
>> (roles=0x20ec8b4, name=1237697304) at vm.c:2348
>> #1  0x00007aa8 in PSRoleTable_growBy_excluding_ (roles=0x22ea08c,  
>> n=36610204, method=0x0) at vm.c:2415
>> #2  0x00007da4 in PSObject_addRoleNamed_at_dispatching_  
>> (obj=0x22da888, name=33637572, position=1, method=0x23b19a0) at  
>> vm.c:2890
>> #3  0x00008f28 in ObjectPointer_asMethod_on_arity_  
>> (method=37427552, selector=33637572, args=0x1, n=2) at vm.c:3068
>> #4  0x0000b2ac in _primitive0 (interpreter=0x2090d44,  
>> arguments=0x49c5c318, argumentsSize=23968, optionals=0x5c54) at  
>> vm.c:3863
>> #5  0x000097c4 in  
>> PSInterpreter_send_to_through_arity_withOptionals_ (i=0x2090d44,  
>> selector=33643540, args=0x22e80e8, dispatchers=0x22e80e8, n=3,  
>> opts=0x0) at vm.c:3406
>> #6  0x0000a780 in PSInterpreter_interpret (i=0x2090d44) at vm.c:1118
>> #7  0x00002de0 in slateMain (argc=2, argv=0xbffff4d4) at ../boot.c: 
>> 196
>> #8  0x000020bc in _start (argc=2, argv=0xbffff4d4,  
>> envp=0xbffff4e0) at /SourceCache/Csu/Csu-57/crt.c:272
>> #9  0x00001f5c in start ()
>>
>> The crash source is at vm.c:2409:
>>
>>     roleName = ((roles -> roles)[index]).name;
>>
>> where roleName is garbage and later dereferenced.
>>
>> Any suggestions? I'm using the main sources and have tried both the
>> alpha and a generated vm.c.
>>
>> Regards,
>>
>> Nick.
>>
>>
>> On 16 Aug 2005, at 16:10, Brian Rice wrote:
>>
>>> Hi, Nick!
>>>
>>> I've been trying GCC 4.0 again on OS X Tiger/G5, and without that  
>>> option it seems to work fine now. I'll check again and see what  
>>> is actually breaking if I can.
>>>
>>> I've also seen reports that GCC 4 can break assumptions about  
>>> argument evaluation order, but I've not been able to reproduce a  
>>> bug under it yet - when I do, I'll be looking for this kind of  
>>> bug, and it's probably a good idea if others do, too.
>>
>

--
-Brian