Re: Lightning loops indefinitely inside jit_emit on M1 Macs

[Paulo César Pereira de Andrade]

Em dom., 7 de mar. de 2021 às 19:17, Darren Kulp <darren@kulp.ch> escreveu:
>
> Hello,

  Hi,

> Thank you for GNU lightning. It is a great tool and I have appreciated how 
> things generally just work. Right now, I am seeing a rare exception to that 
> rule: when I build GNU lightning 2.1.3 on my M1 Macbook (arm64 architecture), 
> the generated example codes appear to hang inside jit_emit().
>
> The script below shows what I know so far.
>
> curl -O http://ftp.gnu.org/gnu/lightning/lightning-2.1.3.tar.gz
> tar xf lightning-2.1.3.tar.gz
> cd lightning-2.1.3
> CFLAGS=-g3 LDFLAGS=-g3 ./configure && make
> DYLD_LIBRARY_PATH=$PWD/lib/.libs ./doc/.libs/rfib &
> sleep 5 # arbitrary sleep time to allow to get stuck
> lldb -p $(pgrep rfib)
>
>
> After those commands, an LLDB backtrace shows this :
>
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0x000000018e6259c8 libsystem_kernel.dylib`__mmap + 8
>     frame #1: 0x000000018e625954 libsystem_kernel.dylib`mmap + 52
>     frame #2: 0x000000010025b870 
> liblightning.1.dylib`_jit_emit(_jit=0x0000000127e06970) at lightning.c:2065:23
>     frame #3: 0x0000000100237d2c rfib`main(argc=1, argv=0x000000016fbcb940) 
> at rfib.c:47:9
>     frame #4: 0x000000018e679f34 libdyld.dylib`start + 4
>
> Stepping through the code, it appears that the code is stuck in the loop 
> starting at line 2033 of lightning.c, and that emit_code() continues to 
> return NULL each time it is called.

  This should only happen if while generating jit, it notices the instruction
pointer in the mmap'ed area would overflow.

  Can you run under a debug environment? It would be very valuable
to know what value _jit.length has in the first call to emit_code. It
should have calculated a sane value, but to enter an infinite loop,
it probably has a negative, and very small value, as it increments
the size in 4k at a time, and tries again. It really should not even
loop, as it should never miscalculate that bad.

  To debug this issue, it should be enough to set a breakpoint in
_jit_emit, then a watchpoint on *(long*)_jit->code.length

  Should also check what value _jit->code.end has, as it might also
be somehow getting an incorrect value, but in all conditions, it
should be due to bad code generation. Can you also share all
build logs? Maybe the compiler its giving some advice of some
issue that my test environment on Linux and gcc did not have.

> I noticed this problem first when I tried to use Homebrew to install GNU 
> lightning on my mac. Homebrew has “bottles” (binary distributions) compiled 
> for Intel platforms including macOS Big Sur, but not for M1 Macs as of this 
> writing.
>
> kulp@ego /tmp % brew install lightning
> Error: lightning: no bottle available!
> You can try to install from source with:
>   brew install --build-from-source lightning
>
> When I tried to install using `brew install --build-from-source lightning`, I 
> noticed that the `check` process took 100% CPU for a long time (over an 
> hour), so I guessed it must be in an infinite loop, and tried to build it 
> myself as I had previously done successfully on Intel Macs. That is when I 
> discovered the details I show above.
>
> I would have tried to reproduce the issue on master, but I get stuck with 
> autoconf (my autoconf 2.69 rejects some directives in configure.ac).
>
> In a few days I will regain access to my Intel Mac (with older macOS version 
> of High Sierra instead of Big Sur), for comparison. Until then, can anyone 
> suggest something else I could try in order to narrow things down ?
>
> Darren Kulp

Thanks!
Paulo