segfault on x86 when built with shared libuv

[kapouer]

Version

20.19.0

Platform

Linux barriere 6.1.0-33-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.133-1 (2025-04-10) i686 GNU/Linux

Subsystem

fs

What steps will reproduce the bug?

Using nodejs built with shared libuv,

git clone https://github.com/nfroidure/svgicons2svgfont
cd svgicons2svgfont
npm install
npm run build
jest src/tests/cli.test.ts

How often does it reproduce? Is there a required condition?

I built a libuv as shared library using upstream libuv 1.46.0, with or without nodejs patches,
Once built, I do
LD_PRELOAD=~/libuv-1.46.0/.libs/libuv.so.1.0.0 jest src/tests/cli.test.ts

What is the expected behavior? Why is that the expected behavior?

No segfault, as when compiled with static linking of deps/uv/

What do you see instead?

Thread 1 "node" received signal SIGSEGV, Segmentation fault.
0xf567df57 in std::default_delete<node::fs::FSContinuationData>::operator() () at /usr/include/c++/14/bits/unique_ptr.h:93
93		delete __ptr;
(gdb) bt
#0  0xf567df57 in std::default_delete<node::fs::FSContinuationData>::operator() () at /usr/include/c++/14/bits/unique_ptr.h:93
#1  std::unique_ptr<node::fs::FSContinuationData, std::default_delete<node::fs::FSContinuationData> >::~unique_ptr ()
    at /usr/include/c++/14/bits/unique_ptr.h:399
#2  node::fs::FSReqBase::~FSReqBase () at ../src/node_file.cc:224
#3  0xf569ae5d in node::fs::FSReqCallback::~FSReqCallback () at ../src/node_file.h:203
#4  node::fs::FSReqCallback::~FSReqCallback () at ../src/node_file.h:203
#5  0xf5669de9 in node::BaseObjectPtrImpl<node::ReqWrap<uv_fs_s>, false>::~BaseObjectPtrImpl () at ../src/base_object-inl.h:186
#6  node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper () at ../src/req_wrap-inl.h:127
#7  0xf4a6ffe0 in uv__work_done (handle=0xf4a9f6a0 <default_loop_struct+96>) at ./src/threadpool.c:330
#8  0xf4a74129 in uv__async_io (loop=0xf4a9f640 <default_loop_struct>, w=<optimized out>, events=<optimized out>) at ./src/unix/async.c:208
#9  0xf4a8a3db in uv__io_poll (loop=<optimized out>, timeout=<optimized out>) at ./src/unix/linux.c:1571
#10 0xf4a75041 in uv_run (loop=0xf4a9f640 <default_loop_struct>, mode=UV_RUN_DEFAULT) at ./src/unix/core.c:460
#11 0xf556b1d7 in node::SpinEventLoopInternal () at ../src/api/embed_helpers.cc:41
#12 0xf56caf09 in node::NodeMainInstance::Run () at ../src/node_main_instance.cc:111
#13 node::NodeMainInstance::Run () at ../src/node_main_instance.cc:104
#14 0xf56cb323 in node::NodeMainInstance::Run () at ../src/node_main_instance.cc:100
#15 0xf56268ef in StartInternal () at ../src/node.cc:1520
#16 node::Start () at ../src/node.cc:1527
#17 0x56556087 in main () at ../src/node_main.cc:97

Additional information

No segfault on amd64, armhf or even s390x.
Any idea where to look ?

[bnoordhuis]

Maybe you built one or the other with (or without) _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64? The fact it happens in node_file.cc but only in the 32 bits x86 build suggests it's something like that.

[kapouer]

Yes, that was it - shared libuv compiled with _FILE_OFFSET_BITS=64 and nodejs compiled without.
Thanks.