Re: Troubles with OSX

Hi Cyril and Frederic.

Ahh - of course, I forgot about SmartEiffel stripping the executable.  :-)

I also forgot to mention that I'm running an Intel mac, not a PowerPC mac (it's a MacBook Pro).

Well, I compiled my test application with '-g -no_strip' and found out where it's dying.  The application I'm running is basically a large unit test app for a data structure library that I've built up over the years using SmartEiffel.  The particular code it's dying on relates to when I'm inserting values into an AVL set that I wrote.  The exact C code is in a gc_mark function.  In particular:

    typedef struct S368 T368;
    struct S368{T2 _element;T0* _parent;T0* _left;T0* _right;T0* _prev;T0* _next;T2 _level;};

    void gc_mark368(T368*o){
    begin:
    if(((gc368*)o)->header.flag==FSOH_UNMARKED){
    ((gc368*)o)->header.flag=FSOH_MARKED;
#   /*7p*/if(NULL!=o->_next)gc_mark368((T368*)(o->_next));
    /*7p*/if(NULL!=o->_prev)gc_mark368((T368*)(o->_prev));
    /*7p*/if(NULL!=o->_right)gc_mark368((T368*)(o->_right));
    /*7p*/if(NULL!=o->_left)gc_mark368((T368*)(o->_left));
    o=(void*)o->_parent;
    if((o!=NULL))goto begin;
    }
    }

It's dying on the line denoted by the '#'.  This structure refers to a node in my tree, which contains pointers to the left and right children as well as pointers to the next and previous nodes (ordered over the elements of the set).  The exact error message is:

    Program received signal EXC_BAD_ACCESS, Could not access memory.
    Reason: KERN_PROTECTION_FAILURE at address: 0xbf7ffffc
    0x00060963 in gc_mark368 (o=0x1bdd058) at tst11.c:8784
    8784    /*7p*/if(NULL!=o->_next)gc_mark368((T368*)(o->_next));

The odd thing is that the address 0xbf7ffffc is always the offending address, even when I encounter this error in other applications.  Is there anything else I can do to shed some more light?

Phil.

Cyril ADRIAN wrote:

Hi Phil,

On Mon, May 5, 2008 at 2:52 AM, Phil Malin philmalin@... wrote:
  

 I've tried to debug one of my apps using gdb but to be honest I don't have
much experience with this debugger and am not getting back too much info
(the routine it says where it's dying at is just an empty string).
    

Tip: try using the -g -no_strip flags, you'll have a real backtrace.

If it's GC-related, occurs on OSX but not on BSD, I'm a bit at a loss.
A problem with mark_stack_and_registers() maybe??

  

I've
been able to reproduce the issue easily enough in one of my apps and the
Eiffel code where it's occurring seems harmless enough - it's simply a
reference equality check (I determined this using logging statements).
    

Maybe it's silly, but did you try activating assertions? Something
like -all_check -sedb?

Best regards,