Re: [eclipse-clp-users] Question about recursion frames in ECLiPSe-CLP

Schüpbach Adrian Laurent wrote:
> Dear ECLiPSe-team
> 
> I'm trying to port ECLiPSe-CLP to a new OS we are currently writing and I'd
> have some questions.
> 
> I started with the minimal set of files needed to build Kernel/<arch>/sepia
> and wanted to get that working first. That means I take the files
> in Kernel/ and Shm/ and I build libeclipse, libshm and libdummies and
> finally link it together with a simple example (eg_c_basic).
> 
> I'm using version 6.0.42.
> 
> I can compile and link the example file which does
> ec_init(), ec_post_string(), ec_resume(), ec_queue_read() and
> ec_cleanup().
> 
> When I try to run it, ec_init() almost terminates, but not completely.
> It reads in lib/kernel.eco and parses it, that seems ok.
> 
> At some point, just before ec_init() terminates, ec_emulate() returns with
> PTHROW due to a recursion frame. PTHROW is returned by
> emu.c at around line 6600 where it checks for the recursion frame.
> 
> 
> I have some questions about that:
> 
> 1. What is a recursion frame and why does it usually get pushed?

It gets pushed when a new (possibly nested) emulator is entered.


 > 2. Why would the recursion frame not be expected at this point?

It is not in itself the cause of the problem.  It probably means that
the emulator is being exited as a consequence of an error during abstract
machine code execution.


> 3. Which emulator is exited here? Are there several emulators?

During booting, there is an outer emulator invocation, which executes
the prolog goal load_eco(".../kernel.eco",...).
The load_eco/4 predicate reads directives from the kernel.eco file
and executes them one by one, using a new nested emulator for each.
Your problem very likely occurs during the execution of one of these
directives, which leads the nested emulator to abort.

Can you verify this by checking if you indeed have two nested
invocations of ec_emulate at that point?


> 4. Is there anything I can look for to identify the problem?

First, use configure --enable-debug and rebuild everything.

This will, among other things, enable the abstract instruction
backtracing facility: using a debugger like gdb, you can
then at any time invoke the function lastpp(<n>) to get a
backtrace of the last <n> abstract instructions executed.
This should give an idea of what caused the error.


> 5. Is there any detailed code documentation?

Additional documentation is in documents/internal/kernel.


> ...
> 
> 
> Unfortunately I don't fully understand the code and the execution flow there.
> I hope you can give me some hints what I should look for or how I could
> try to debug.

Problems during the boot phase are of course difficult to track down.
Please email me directly if it gets too detailed for the mailing list!


> 
> Thank you in advance!
> 
> Cheers
> Adrian


-- Joachim