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:
> 
> 
>     Colin> So I tried the following options:
> 
>     Colin> ./configure --enable-large-config --enable-gc-debug
>     Colin> --enable-gc-assertions --prefix=/usr/local
> 
>     Colin> but now the problem no longer occurs in the original case.
> 
>     Colin> However, it is still crashing further on:
> 
>     Colin> 'stack_trace_string' in 'eif_except.h' not implemented Call
>     Colin> on Void target!  Unhandled exception
> 
>     Colin> Perhaps this is a different problem.
> 
> When running under the gdb I get:
> 
> Call on Void target!
> [Switching to Thread -1208531248 (LWP 755)]
> 
> Breakpoint 1, GE_raise (code=1) at gestalt_test_driver48.c:24535
> 24535           GE_rescue* r = GE_last_rescue;
> (gdb) 
> 
> (gdb) backtrace
> #0  GE_raise (code=1) at gestalt_test_driver48.c:24535
> #1  0x09afbe26 in GE_check_void (obj=0x0) at gestalt_test_driver48.c:24608
> #2  0x08bc2571 in T1480f305 (ac=0xbfc2dfcc, C=0xb817540, a1=0xb447cb0)
>     at gestalt_test_driver20.c:27100

In order to make sense out of this execution trace I would
need to have a look at the generated .h file, so that we can
translate the generated C function names to the corresponding
Eiffel feature names. How big is this file?

Either the call-on-void-target is real, or some not-yet-implemented
parts of gec that can trigger this wrong behaviors are:

* use of user-defined expanded classes
* call to external routines returning an object whose type
   is not a basic expanded type or STRING.

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