lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Lightning loops indefinitely inside jit_emit on M1 Macs


From: Darren Kulp
Subject: Lightning loops indefinitely inside jit_emit on M1 Macs
Date: Sun, 7 Mar 2021 17:16:58 -0500

Hello,

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.

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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]