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

Hi Joachim

Thank you for your help. I looked a bit further to it and I try to summarize
here what I could find out. I hope this is not too detailed/too long for the list.


> > 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?


Indeed, I have two nested emulators at that point. I looked a bit closer
to the execution chain just before that to possibly find out the error
caused by the inner emulator.

At some point, sub_emulc_noexit() is called and a bit later
_queue_flush(stream_id nst).

Here the if-clause
if ((StreamMode(nst) & SYIELD) && (StreamMode(nst) & MWRITE))
is true and YIELD_ON_FLUSH_REQ is returned.
After that, _bip_err1_: in emu.c is called with err_code = YIELD_ON_FLUSH_REQ.

Could that be the error which is generated by the nested emulator?

Would that mean, that a certain queue can't be flushed for some reason?
Which queue would that be?

Right after that, the same thing happens a second time and then it goes
to the function which checks for the recursion frame and which returns PTHROW.
So it might be that the outer emulator also tries to flush the queue right after
the inner one exited?



> > 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.


Unfortunately I can't run ./configure on our system, however I added the
definitions -DDEBUG -DLASTPP -DPRINTAM to the CFLAGS and I have lastpp(<n>)
defined/compiled in.

My gdb somehow doesn't like calling the function in debug mode, so I just
added the call lastpp(5); in emu.c at about line 6610 where it checks
for the recursion frame and just before calling goto _exit_emulator_;
with err_code = PTHROW.

_queue_flush(stream_id nst) returns now 5 extra times YIELD_ON_FLUSH_REQ
per emulator.
Is it possible, that lastpp(5) couldn't output anything, because it was not
able to flush the queue?
Unfortunately I can't see the last executed goals like this for the moment.


How are these queues working and how should they be flushed? What could go
wrong with this?

Thanks you very much!

Cheers
Adrian