#216 ECL missing signals?

HEAD
closed
nobody
None
1
2014-09-23
2012-11-27
No

Dear all,

We encountered the following problem in Sage, which seems to be
present in ECL: run an infinite loop and try to interrupt it,
sometimes the interrupt is missed.

For example, at ECL prompt:

(setf i 0)

0

(defun infinite() (loop (incf i)))

INFINITE

(infinite)

Now press CTRL+C.
Most of the time, the loop will be broken, but sometimes you'll just
get a nice ^C on screen.
I've got no problem with this test with the old version of ECL used in
Sage: ecl-11.1.2.cvs20111120.

The problem may be deeper, because we also sometimes fails to evaluate
'2', which is quite surprising!

Best,

--
Jean-Pierre Flori

Discussion

  • OK I think I got it.
    The culprit is commit 880259cb5533913a6c09d6c99d8d26a22e1b9195.

    I hirst thought that the following change was to be blamed:
    --- a/src/c/main.d
    +++ b/src/c/main.d
    @@ -77,7 +77,7 @@
    1, / ECL_OPT_TRAP_SIGCHLD /
    1, / ECL_OPT_TRAP_INTERRUPT_SIGNAL /
    1, / ECL_OPT_SIGNAL_HANDLING_THREAD /
    - 128, / ECL_OPT_SIGNAL_QUEUE_SIZE /
    + 16, / ECL_OPT_SIGNAL_QUEUE_SIZE /
    0, / ECL_OPT_BOOTED /
    8192, / ECL_OPT_BIND_STACK_SIZE /
    128, / ECL_OPT_BIND_STACK_SAFETY_AREA /
    but changing this back in git HEAD from some time yesterday does not
    fix the issue.

    (By the way, not sure why we don't use threaded ECL in Sage, I guess
    that our current signal handling would be completely broken as a first
    good enough reason, not really sure there are other reasons.)

    Best,

    --
    Jean-Pierre Flori

     

  • Anonymous
    2012-11-27

    I might have found a simpler way to get this: just launch ecl and then
    press CTRL+C, you'll get an ^Coups, repress them and the interurpt
    will get caught.

    And if try the same thing with a thread enabled ECL, the interrupt get
    caught, but when I quit ECL just after, I get a segfault which seems
    to happen at the end of asynchronous_signal_servicing_thread().

    --
    Jean-Pierre Flori

     

  • Anonymous
    2012-11-27

    There are two strange things in the non threaded case:
    - it seems that as soon as one tries to queue_signal something, it ends up in the else clause I added (i.e. it always fails)
    - when you get at the ECL prompt, the_env->disable_interrupt is non-zero.

     

  • Anonymous
    2012-11-27

    Ok, I think line 380 should read
    [TAB][TAB][TAB]record = env->signal_queue;

    This does not solve my segfault problem with the multithreaded ecl.

    One last remark, with this modification, queued interrupts gets treated in reversed order (ie kind of FILO queue), is this intended?

     
  • Here comes the simple diff, not sure if i should post this in the patch tab as well.

     
    Attachments
  • Seems my previous post got lost in this application. The three problems are now solved:

    • typo when extracting the conses from the signal buffer
    • wrong order of signals in the queue
    • a SIGSEGV when the asynchronous signal handling thread exits
     
    • status: open --> closed
     


Anonymous


Cancel   Add attachments