Invalid memory access with --release and --debug

[wooster0]

Steps to reproduce:

1. Clear Crystal's cache using sudo rm -rf ~/.cache/crystal/.
2. Compile a program (can be empty) with --release and --debug.

Output should be:

Invalid memory access (signal 11) at address 0x1c
[0x7f6f114a3836] ???
[0x7f6f10a18f00] ???
[0x7f6f128ea445] ???

I first encountered this without my cache cleared. It always happened when I changed my program. When I compiled with the same program again, I did not get an Invalid memory access (however doing the above always results in an Invalid memory access. My old cache was probably at a specific glitchy state at this point).

But that's not all. There's also something else to reproduce:

1. Clear Crystal's cache again using sudo rm -rf ~/.cache/crystal/.
2. Compile a program (can be empty) without any flags.
3. Compile this program:

   {% flag?(:release) && flag?(:debug) %}

   with --release and --debug.

Output should be:

Invalid memory access (signal 11) at address 0x1c
[0x7f52fcaa3836] ???
[0x7f52fc018f00] ???
[0x7f52fdeea445] ???

And now compile this program again with --release and --debug and the output should be much longer: GitHubGist.
After that the output no longer changes.
I'm very sure this is a bug in the cache.

[repomaa]

Seeing this too. Are you saying the invalid memory access is supposed to happen?

[wooster0]

No, it's not supposed to happen of course. But it would be strange if it doesn't happen to someone with the same version.

[repomaa]

Right. It's a bit annoying since I can't build anything for production that would output usable stacktraces on uncaught exceptions. Have you found any way around it?

[repomaa]

I'm glad that it's so easily reproducable at least. echo | crystal eval --release --debug

[wooster0]

No I haven't found any workaround so far :/
My usecase would be to allow debug features in production builds.

[repomaa]

Exactly my usecase too. We use sentry in production and it's pretty much useless without a readable trace.

[asterite]

--debug is not needed for good traces

[repomaa]

@asterite care to elaborate?

[ysbaddaden]

Debug line numbers are always emitted unless you pass --no-debug, so you don't need --debug for file:line:column in backtraces. The purpose of --debug is to add type debug information for actual debug in gdb or lldb.

[repomaa]

Hm maybe this is unrelated but all i see is ??? in my backtraces, regardless if i use --no-debug or not. I'm building with shards build --production --release.

But I can confirm your statement, that it should work. I created a test project with crystal init app and then raised in a series of function calls and got a beautiful stacktrace.

[ysbaddaden]

The stack is corrupted so the stack unwinding reported bogus adresses, an we can't decode it to a nice file:line backtrace.

[repomaa]

does the --static flag have something to do with this? I just added a Dockerfile to the same project and get the following output when i run the image:

Raising...
Invalid memory access (signal 11) at address 0x0

Here's the Dockerfile:

FROM jreinert/crystal-alpine AS build

WORKDIR /project
ADD . /project

RUN shards build --production --static --release

FROM scratch
COPY --from=build /project/bin/test /bin/test

CMD ["/bin/test"]

and the source:

def one
  raise "something went wrong"
end

def two
  one
end

def three
  two
end

puts "Raising..."
three

[ysbaddaden]

@jreinert this is #4276 unwinding the stack is broken in binaries statically built against musl-libc (hence raise is broken too).

[Daniel-Worrall]

I'm getting similar results from crystal spec -d on an app skeleton. Unsure if it's the same/related.

Invalid memory access (signal 11) at address 0x7fca826f6f08
[0x488536] *CallStack::print_backtrace:Int32 +118
[0x476140] __crystal_sigfault_handler +192
[0x7fca81591390] ???
[0x7fca826f6f08] ???```

[leonklingele]

This happened multiple times already on my end, finally got a crash inside Travis CI:
https://travis-ci.com/omarroth/invidious/jobs/224122920#L280-L287

[asterite]

First step is to check unsafe calls. I'm seeing a bunch of unsafe calls in indivious.

[leonklingele]

@asterite please excuse my lack of knowledge but what are unsafe calls? Are you referring to https://crystal-lang.org/reference/syntax_and_semantics/unsafe.html?

[asterite]

Yes, but also searching "unsafe" in the repo I found a few to_unsafe calls. Might be the issue, might be not.

[rdp]

Wasn't able to repro in ubuntu 19.10 or OS X 0.31.1 FWIW...

[BlobCodes]

echo | crystal eval --release --debug doesn't give me an error.
Seems to have been fixed. Can this be closed?

[wooster0]

Yup, it seems to be fixed.

I'm getting similar results from crystal spec -d on an app skeleton. Unsure if it's the same/related.

Invalid memory access (signal 11) at address 0x7fca826f6f08
[0x488536] *CallStack::print_backtrace:Int32 +118
[0x476140] __crystal_sigfault_handler +192
[0x7fca81591390] ???
[0x7fca826f6f08] ???```

I can't reproduce this either.