yosys-abc deadlocks on Ubuntu 24.04 (glibc 2.39) when invoked via pipe — works on Ubuntu 22.04

[mguthaus]

Originally filed against The-OpenROAD-Project/yosys#28; refiling here because the issue manifests through the ORFS flow and the workaround lives in ORFS usage rather than yosys source.

Subject

[yosys / yosys-abc interaction]

Describe the bug

yosys-abc invoked by yosys through a pipe deadlocks indefinitely on Ubuntu 24.04 hosts. Yosys remains blocked in pipe_read waiting for output from abc; yosys-abc remains blocked in do_select on its stdin pipe. Both processes sit at 0% CPU. Standalone yosys-abc -s -F script.txt completes the same script in under one second, so the abc binary itself is healthy — only the pipe-driven invocation from yosys hangs.

Expected Behavior

make DESIGN_CONFIG=./designs/asap7/gcd/config.mk synth should complete normally as it does in the upstream openroad/orfs docker image (Ubuntu 22.04 inside).

Environment

• OS (broken): Ubuntu 24.04 LTS, ldd (Ubuntu GLIBC 2.39-0ubuntu8.7) 2.39
• Compiler: g++ 13.3.0-6ubuntu2~24.04.1
• Yosys SHA: 6d2c445ae (Release version 0.64, The-OpenROAD-Project/yosys fork)
• OS (working): Ubuntu 22.04 with glibc 2.35 (the openroad/orfs docker image)

The same source SHA (6d2c445ae) is used in both, so this is a runtime regression rather than a source change.

To Reproduce

# On an Ubuntu 24.04 host with a locally built tree (./build_openroad.sh --local)
source env.sh
cd flow
make DESIGN_CONFIG=./designs/asap7/gcd/config.mk synth
# → never makes it past `Executing ABC pass ... Extracting gate netlist ... to <abc-temp-dir>/input.blif`

A minimal reproducer (no make harness needed):

timeout 60 yosys -p "read_verilog flow/designs/src/gcd/gcd.v; synth -top gcd; abc -liberty flow/platforms/asap7/lib/NLDM/asap7sc7p5t_AO_RVT_FF_nldm_211120.lib.gz" </dev/null

Diagnosis

strace -f -e trace=read,write,pipe2,close,dup2,fork,wait4 on the hung pair shows yosys-abc reading its stdin one byte at a time (line-discipline behavior, as if isatty(0) returns true), echoing each char back to its stdout. After yosys writes the full source /tmp/yosys-abc-…/abc.script\n command and abc echoes it, both deadlock:

762992 read(0, "t", 1)                  = 1
762992 read(0, "\n", 1)                 = 1
762992 write(1, "source /tmp/yosys-abc-AaX2kh/abc"..., 39) = 39
762985 read(5, "source /tmp/yosys-abc-AaX2kh/abc"..., 1023) = 39
762985 read(5, 0x7ffd…, 1023)           = ? ERESTARTSYS    ← blocks here forever

yosys-abc then never produces any more output; yosys blocks waiting for it. 5-minute wait did not unblock. Suggests a libreadline / TTY-detection path in abc that misbehaves with glibc 2.39's pipe semantics.

Workarounds tried

• stdbuf -i 4096 -o 4096 -e 4096 wrapper on yosys-abc: no effect.
• Same binary works inside an Ubuntu 22.04 docker container; same docker-built binary copied onto the 24.04 host also hangs → not a build issue, a runtime/glibc issue.

Current workaround

Run make synth inside the openroad/orfs docker image (Ubuntu 22.04), then continue with locally built OpenROAD for the remaining stages on the host.

[mguthaus]

Confirmed: same hang reproduces on a second Ubuntu 24.04 host (different hardware, also glibc 2.39). Not a one-off local-environment issue.

[maliberty]

Peculiar as we test on Ubuntu 22 & 24 daily without any issue. Are you using the dependency installer on this machine?

[mguthaus]

Yes, I'm using:

source dev_env.sh
sudo ./etc/DependencyInstaller.sh -base
sudo ./etc/DependencyInstaller.sh -common 
./build_openroad.sh --no_init --openroad-args "-DCMAKE_BUILD_TYPE=DEBUG -DENABLE_TESTS=OFF" --local

[mguthaus]

Note the sudo is needed for the second -common because of #4266

[maliberty]

Perhaps this is a dependency issue then. See my suggestion there.

[mguthaus]

Resolved — root cause is a user-side ~/.inputrc rebinding, not glibc/libreadline.

After more digging, this isn't a glibc 2.39 / libreadline 8.2 regression. It's a user-environment issue that happens to surface on
24.04-class systems where dotfile templates are more aggressive. The two Ubuntu 24.04 hosts I confirmed it on were both seeded from
the same dotfile setup, which is why both reproduced the hang — not the OS itself. Apologies for the misleading initial diagnosis.

What's actually going on

yosys spawns yosys-abc -s with stdin/stdout connected to pipes (long-lived reuse, gated by REUSE_YOSYS_ABC_PROCESSES in
passes/techmap/abc.cc:166). On the abc side, interactive mode uses GNU readline() to read commands. readline() reads /etc/inputrc
then ~/.inputrc for keybindings regardless of whether stdin is a TTY or a pipe.

My ~/.inputrc had (a common dotfile pattern for vim-tmux-navigator passthrough):

"\C-h":
"\C-j":
"\C-k":
"\C-l":

i.e. each control key rebound to an empty macro so bash/readline won't consume them and tmux/screen can pick them up for pane
navigation.

\C-j is \n. With that binding active, readline() doesn't treat newline as line-terminator anymore — it discards it. So when yosys
writes "source /tmp/yosys-abc-…/abc.script\n" into abc's stdin pipe, abc's readline() reads all the bytes including the \n, never
returns, and yosys blocks waiting for abc's response. Both processes end up in pipe_read.

Why the project's own CI / docker images don't reproduce it

• The openroad/flow-ubuntu24.04-builder image is identical to my host in every way that mattered (Ubuntu 24.04.4, libreadline
  8.2-4build1, gcc 13.3, identical yosys-abc ELF, both linked against libreadline.so.8.2). Same binary copied across hosts: deadlocks
  on my host, runs in 1.25 s in the container.
• The container just has no ~/.inputrc for root, so readline() falls back to defaults and \n terminates a line normally.
• The reason both of my Ubuntu 24.04 boxes hung was that they share the same ~/.inputrc from my personal dotfiles — not that 24.04
  itself is the trigger.

So the earlier strace ("yosys-abc reading 1 byte at a time and echoing") was real but its cause was the inputrc, not the OS
upgrade.

Fix

I no longer use vim-tmux-navigator, so I just dropped those \C-h/\C-j/\C-k/\C-l rebindings from my ~/.inputrc and the flow runs
normally. Anyone hitting the same hang should check their ~/.inputrc (and /etc/inputrc) for empty rebindings of \C-j or \C-h. If
you do need to keep them for terminal multiplexer pass-through, setting INPUTRC=/dev/null in the shell that drives the flow is a
clean workaround.