Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Illegal instruction (4) after second stack overflow on REPL #2815

Closed
danluu opened this issue Apr 10, 2013 · 7 comments
Closed

Illegal instruction (4) after second stack overflow on REPL #2815

danluu opened this issue Apr 10, 2013 · 7 comments
Labels
bug Indicates an unexpected problem or unintended behavior system:mac Affects only macOS

Comments

@danluu
Copy link
Contributor

danluu commented Apr 10, 2013

The first invocation reports a stack overflow, as expected. The second invocation crashes the REPL. Oddly, there's a noticeable pause between displaying ERROR: stackoverflow, and in bad at none:2 (repeats 79998 times).

This doesn't crash on @astrieanna's machine, which is fedora 18, 64-bit. I'm using OS X 10.7.5, 64-bit. I did a pull from master immediately before filing this bug, and I still have the problem.

julia> function bad(x)
         bad(x+1)
       end
# methods for generic function bad
bad(x) at none:2

julia> bad(0)
ERROR: stack overflow

 in bad at none:2 (repeats 79998 times)

julia> bad(0)
Illegal instruction: 4
@astrieanna
Copy link
Contributor

When I do the same thing, I get:

julia> function bad(x)
         bad(x+1)
       end
# methods for generic function bad
bad(x) at none:2

julia> bad(0)
ERROR: stack overflow
 in bad at none:2

julia> bad(0)
ERROR: stack overflow
 in bad at none:2

There's no perceptible pause in printing the ERROR line and the in bad line.

@JeffBezanson
Copy link
Member

The pause is of course due to looking up 79998 function addresses (and checking that they're equal to the last one). Stack overflow is hard to recover from. This is after an async signal (SEGV).

@JeffBezanson
Copy link
Member

We may never be free of #33, #503

@ViralBShah
Copy link
Member

Is there anything we can do here? Closing as wontfix for now.

@JeffBezanson
Copy link
Member

@loladiro is figuring out how to fix this.

@JeffBezanson JeffBezanson reopened this Jul 19, 2013
@Keno Keno closed this as completed in c2e9c3a Jul 23, 2013
@Keno
Copy link
Member

Keno commented May 22, 2014

I was revisiting this today and yesterday (with some help by @jchinlee) because I was looking at signals. Writing this down here mostly for my future reference. It turns out that on OS X, sigreturn in longjmp is only executed when restoring the signal mask (I have no idea why this is the case I don't think it should be). The code for that can be seen at [1] and then [2]. Now, in julia we usually call sigsetjmp(buf,0) (which crashes on OS X) rather than sigsetjmp(buf,1) (which doesn't) though not consistently, so you get weird behavior depending on which try/catch block catches the exception.

Nevertheless, while just calling sigreturn is also a proper solution to this particular bug, there is several good reasons for the current solution, chief among them that if we ever want to move to multiple threads it would crash using the SIGSEGV approach as well as of course the performance of a system call for every try/catch block. One thing I noticed is that we should set the thread port rather than the task port for our exceptions to avoid interfering with debuggers (PR in a sec).

One question this does raise is what is happening on FreeBSD. According to the documentation longjmp should call sigreturn, but reading through the source code it doesn't actually. I'll get myself a VM and test this.

[1] http://www.opensource.apple.com/source/Libc/Libc-825.40.1/x86_64/sys/setjmp.s
[2] http://www.opensource.apple.com/source/Libc/Libc-825.40.1/sys/sigtramp.c?txt

@Keno
Copy link
Member

Keno commented May 26, 2014

I did verify that this does not occur in FreeBSD, because they actually check whether you're executing on the signal stack rather than blindly following SS_ONSTACK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior system:mac Affects only macOS
Projects
None yet
Development

No branches or pull requests

5 participants