Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>     Eric> Colin Paul Adams wrote:
>     Eric> One other thing that I would be interested in, even if it
>     Eric> does not crash at the same location each time, is to know at
>     Eric> which stage in the execution trace the message "Unhandled
>     Eric> exception" is printed.  Could you try to put a break point
>     Eric> in the C code at the beginning of the C function 'GE_raise'
>     Eric> and see what the execution trace looks like?
>     >>> 
>     >>> How do I set a break point?
> 
>     Eric> I don't know. I guess it depends on the C debugger that is
>     Eric> available under Linux. Under Windows I do that from Visual
>     Eric> Studio.
> 
>     Colin> OK - I'm using gdb.
> 
>     Colin> I need to know which file to find GC_RAISE in. Is it part
>     Colin> of gec or boehm?  -- Colin Adams Preston Lancashire
> 
> Never mind - when i spelt it right, gdb found it.
> 
> But it doesn't break there:

If it does not break here, then it means that it does not
print "Unhandled exception", does it?

> (gdb) break GE_raise
> Breakpoint 1 at 0x9afba75: file gestalt_test_driver48.c, line 24535.
> (gdb) run
> Starting program: /home/colin/gestalt/test/gestalt_test_driver --case=accessor20_018_01
> [Thread debugging using libthread_db enabled]
> [New Thread -1209092400 (LWP 17574)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1209092400 (LWP 17574)]
> GC_clear_fl_links (flp=0xb84ee50) at reclaim.c:469
> 469            *flp = 0;
> (gdb) 
> (gdb) backtrace
> #0  GC_clear_fl_links (flp=0xb84ee50) at reclaim.c:469
> #1  0x09b02382 in GC_start_reclaim (report_if_found=0) at reclaim.c:504
> #2  0x09b05c47 in GC_finish_collection () at alloc.c:680
> #3  0x09b09415 in GC_alloc_large (lb=3016, k=1, flags=0) at malloc.c:53
> #4  0x09b09719 in GC_generic_malloc (lb=3015, k=1) at malloc.c:171
> #5  0x09b098ba in GC_core_malloc (lb=3015) at malloc.c:286
> #6  0x0804ace6 in GE_ms (
>     s=0x9b50518 "%G�%@\204\215%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G�%@\204\215$(CBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBe%G�%@(B\204\215%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@"..., c=3003) at gestalt_test_driver1.c:1882
> #7  0x09afa725 in GE_const_init () at gestalt_test_driver48.c:21933
> #8  0x09afba25 in main (argc=Cannot access memory at address 0x0
> ) at gestalt_test_driver48.c:24448
> (gdb) 

It did not go very far. It is just creating the manifest constants.
It didn't even start the root creation procedure yet.

As you can see, it looks like a bug in the GC. Or the GC is not
configured correctly. Perhaps we need to compile it with another
option than -DLARGE_CONFIG.

Perhaps I should try to plug with another GC. Any suggestion?
There is:

   http://www.hoard.org/

but it does not seem to have GC functionality.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com