Failed to raise an exception when using raise in a Duktape function (ARM only)

[hkalexling]

First of all, thanks for your work on this amazing shard!

I noticed this weird issue when using Duktape.cr in my app, and I am not sure if it's related to this shard, the original duktape library, or the Crystal lang. It only happens on ARM32 so it's a bit tricky to reproduce.

Steps to reproduce:

1. Cross-compile the following code to ARM32. The command I used is crystal build src/duktape-raise.cr --release --progress --error-trace --cross-compile --target='arm-linux-gnueabihf' -o arm32

require "duktape/runtime"

rt = Duktape::Runtime.new do |sbx|
  sbx.push_global_object

  sbx.push_proc 1 do |ptr|
    env = Duktape::Sandbox.new ptr
    msg = env.require_string 0
    env.call_success

    raise msg
  end
  sbx.put_prop_string -2, "raise"
end

rt.eval <<-JS
raise('I am an error');
JS

This generates an object file arm32.o ready to be linked on ARM32.

2. Link the object file on ARM32.
3. Run the executable, and get the following error:

Failed to raise an exception: FAILURE
[0x4005b4d4] ???
[0x40014194] __crystal_raise +40
[0x40014724] ???
[0x4001464c] ???
[0x4005996c] ???

Tried to raise:: I am an error (Exception)
  from home/alex_ling/duktape-raise/lib/duktape/src/duktape/sandbox.cr:21:0 in '->'

Expected behavior:

If compiled and run on AMD64, it works as expected and raises the correct expcetion:

Unhandled exception: I am an error (Exception)
  from src/duktape-raise.cr:11:5 in '->'
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from duk_eval_raw
  from lib/duktape/src/duktape/api/eval.cr:118:7 in 'eval_string'
  from lib/duktape/src/duktape/api/eval.cr:122:19 in 'eval_string!'
  from lib/duktape/src/duktape/api/eval.cr:32:7 in 'eval!'
  from lib/duktape/src/duktape/runtime.cr:143:7 in 'eval'
  from src/duktape-raise.cr:16:1 in '__crystal_main'
  from /usr/share/crystal/src/crystal/main.cr:110:5 in 'main_user_code'
  from /usr/share/crystal/src/crystal/main.cr:96:7 in 'main'
  from /usr/share/crystal/src/crystal/main.cr:119:3 in 'main'
  from __libc_start_main
  from _start
  from ???

[jessedoyle]

Hi @hkalexling - thanks for using duktape.cr!

While I haven't had a chance to dig into this yet, I'd also like to thank you for a great writeup of the issue with clear reproduction steps.

At first thought, my gut feeling is that the root cause of this bug must live upstream either in Duktape itself or in Crystal core (perhaps in the platform specific code around error handling on ARM32). My reasoning above is simply because duktape.cr doesn't contain any platform specific code for ARM32 (outside of the included native code for Duktape itself).

I have a few thoughts on how this can be tested, but it might be very difficult for me because I don't have any ARM32 devices that run linux. Does anyone know of a cloud provider that can spin up ARM32 instances? To my knowledge, the AWS Gravitron processors are all ARM64.

I've got a few fixes that I'd like to do within the next few weeks for duktape.cr, so as a part of that work I'll start digging into this issue. Just an FYI that it might be very tricky to find a root cause.

[jessedoyle]

Some data from a quick search for the error message in Crystal core: https://github.com/crystal-lang/crystal/blob/dd40a2442fa186add8a82b74edb14a90aa1dae05/src/raise.cr#L196.

To my knowledge, Crystal uses libunwind for its exception handling. I think the issue may stem from an interaction in Crystal core, but I'd like to do a bit more due diligence before opening an upstream issue.

[hkalexling]

Thanks for your reply! When testing it I was using an AMD64 host, but I set up QEMU and started an ARM32 Docker container. I then linked the cross-compiled object file in the container and ran it there. If it would be helpful, I will be happy to share the Dockerfile I used.

[jessedoyle]

Hey @hkalexling! So I started a bit of investigation. You're cross-compiling to arm32 from amd64 right?

If so, I'm just curious - are you compiling the duktape interpreter binary for arm as well?

This shard is written to compile the duktape static library during the postinstall phase. In a cross-compilation scenario, the postinstall phase may occur on the host architecture (amd64/x86_64). I don't suspect this to be the case, but it's worthwhile to check!

Also if you do have a dockerfile you've been testing with, it would be great if you were able to share it with me!

Thanks!

[hkalexling]

Sure! Here's the Dockerfile I used:

FROM arm32v7/ubuntu:18.04

RUN apt-get update && apt-get install -y git make llvm-8 llvm-8-dev g++ libpcre++-dev libgc-dev libssl-dev libcrypto++-dev libevent-dev

RUN git clone https://github.com/crystal-lang/crystal && cd crystal && git checkout 0.36.1 && make deps && cd ..
RUN git clone https://github.com/jessedoyle/duktape.cr && cd duktape.cr/ext && git checkout v1.0.0 && make && cd ..

COPY arm32.o .

RUN cc arm32.o -o arm32 -rdynamic -L/usr/bin/../lib/crystal/lib -L/duktape.cr/src/.build/lib -L/duktape.cr/src/.build/include -lduktape -lm -lpcre -lm -lgc -lpthread /crystal/src/ext/libcrystal.a -levent -lrt -ldl

CMD ["./arm32"]

The arm32.o file was created on the AMD64 host. As you can see in the Dockerfile, I cloned and compiled duktape in the Docker container and not the host.

I understand that this kind of issue is challenging to debug, so please take your time, and let me know if you need any information or help from my side!