Segmentation fault where stack overflow expected

[mbauman]

This was a funny typo:

julia> function f()
           global f() = "hi"
           f()
       end
f (generic function with 1 method)

julia> f()
Segmentation fault: 11

Definitely an error, but probably shouldn't segfault.

[yuyichao]

Is there a stack trace and is this mac?

[JeffBezanson]

Yes, probably due to stack overflow. The new definition should not be visible inside f, so I believe this is equivalent to f() = f(). Does that also segfault?

[mbauman]

No stack trace. This is a mac. And f() = f() correctly throws a stack overflow. With julia-debug the original example is also a stack overflow.

julia> versioninfo()
Julia Version 0.6.0-pre.alpha.155
Commit 09e7ef2 (2017-03-16 17:40 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin14.5.0)
  CPU: Intel(R) Core(TM) i5 CPU       M 520  @ 2.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT NO_AFFINITY NEHALEM)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, westmere)

julia> f() = f()
f (generic function with 1 method)

julia> f()
ERROR: StackOverflowError:
Stacktrace:
 [1] f() at ./REPL[2]:1 (repeats 80000 times)

[StefanKarpinski]

@yuyichao: can you please explain why you closed this?

[yuyichao]

Dup of #17280 ..... Forgot to link...

[mbauman]

Given that #17280 is no longer a segfault, I don't think this is a dup.

[yuyichao]

Sure we can move to this one but this is still a dup of #17280. The code that triggers the issue has been very system dependent and doesn't trigger the issue on the same system all the time either.

[mbauman]

I can reproduce #17280 on 0.5. It's fixed on 0.6.

[yuyichao]

So copying my request for more info from #17280 (comment)

If you run this in GDB, and when the segfault happens, can you set a breakpoint in cache_exception_raise and single step to after the thread_get_state call and check the following when you hit the breakpoint due to the segfault?

1. p *ptls2 (if ptls2 is optimized out, try p *jl_all_tls_states[0])
2. p exc_state.__faultvaddr
3. thread apply all p $rsp
4. thread apply all p $rbp

[yuyichao]

I can reproduce #17280 on 0.5. It's fixed on 0.6.

This doesn't mean that the issue is fixed. It just means that we somehow triggers a slightly different code path (or whatever it was) that the buggy stackoverflow detection happens to be able to handle.

[yuyichao]

This might also be a dup of #14284 and related to #13294 but without the info I've been requesting it's very hard to tell..................................................

[yuyichao]

Also note that the same debugging should be done on the now incorrectly closed #17280 as well since it's most likely that the issue disappeared for unrelated reason and it's important to check if the two are actually crashing for exactly the same reason (or if the signal handler/unwinder has more than one issue)

[mbauman]

I can no longer reproduce the original example on either 0.6.0 or master.