Summary

Runaway stack problem

Metadata

• Id: 172150fd85ad960f3a9252edffbb74ef9f6104e7
• Trac id: 1283
• Type: defect
• Reporter: sjamaan
• Owner:
• Cc:
• Status: closed
• Component: core libraries
• Estimated difficulty:
• Resolution: fixed
• Priority: critical
• Milestone: 4.11.0
• Version: 4.10.x
• Changetime: 2016-04-27 13:36:39 UTC
• Created: 2016-04-21 21:00:45 UTC
• Keywords:

Description

Occasionally we still run out of stack. See for example:

• Today's|Salmonella run of scsh-process] (somewhere halfway down the page is an ERROR)
• Stack|overflow in scsh-process, experienced by TheLemonMan]
• Valgrind|run of the above]

Changes and comments

[2016-04-24 14:31:09 UTC] sjamaan wrote:

OK, the reason for this is extremely simple and I don't understand why this hasn't caused problems before:

- When a signal is received by the process, we call C_raise_interrupt, which resets the stack pointer to the bottom of the stack, so that the stack checks "think" the stack is full (while really it isn't) - Normally, a C_demand() call will take care of handling this by triggering a GC/signal handler. - A C_stack_overflow_check (or a direct call to C_stack_check1) performs more or less the same checks as C_demand() does, so if this is the first thing that happens after a signal arrived, it will simply bomb. That's why sometimes it shows a stack overflow error and other times a C_CIRCULAR_DATA_ERROR, if the signal happens **just** before a call to equal?.

[2016-04-27 13:36:39 UTC] evhan changed status from new to closed

[2016-04-27 13:36:39 UTC] evhan set resolution to fixed

[2016-04-27 13:36:39 UTC] evhan wrote:

Fixed by 5d2a17a, f2ed421, 10ef6f6.