Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault on output executable #101

Open
OvercookedBeef opened this issue Oct 6, 2024 · 3 comments
Open

Segmentation fault on output executable #101

OvercookedBeef opened this issue Oct 6, 2024 · 3 comments

Comments

@OvercookedBeef
Copy link

I was following the instructions for SEA from here.

Here are my steps:

$ node --experimental-sea-config sea-config.json
Wrote single executable preparation blob to sea-prep.blob
$ cp $(command -v node) "sea_linux"
$ npx postject "sea_linux" NODE_SEA_BLOB sea-prep.blob --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2
Start injection of NODE_SEA_BLOB in sea_linux...
warning: Can't find string offset for section name '.note'
💉 Injection done!
$ ./sea_linux 
Segmentation fault (core dumped)

Here's my sea-config.json:

{
    "main": "index.js",
    "output": "sea-prep.blob"
}

I ran it with GDB and here's the output, not sure if it's helpful:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fd4867 in _dl_relocate_object (l=l@entry=0x7ffff7ffe2e0, scope=<optimized out>, reloc_mode=<optimized out>, 
    consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:301
301         ELF_DYNAMIC_RELOCATE (l, scope, lazy, consider_profiling, skip_ifunc);
(gdb) bt
#0  0x00007ffff7fd4867 in _dl_relocate_object (l=l@entry=0x7ffff7ffe2e0, scope=<optimized out>, reloc_mode=<optimized out>, 
    consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:301
#1  0x00007ffff7fe7071 in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, 
    auxv=<optimized out>) at rtld.c:2314
#2  0x00007ffff7fe3786 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffe320, 
    dl_main=dl_main@entry=0x7ffff7fe53e0 <dl_main>) at ../sysdeps/unix/sysv/linux/dl-sysdep.c:141
#3  0x00007ffff7fe50de in _dl_start_final (arg=0x7fffffffe320) at rtld.c:494
#4  _dl_start (arg=0x7fffffffe320) at rtld.c:581
#5  0x00007ffff7fe3dc8 in _start () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffe6d3 in ?? ()
#8  0x0000000000000000 in ?? ()
@OvercookedBeef
Copy link
Author

Looks like the same issues as what this person had: #76 (comment)

I'm also on Arch linux.

@OvercookedBeef
Copy link
Author

OvercookedBeef commented Oct 6, 2024

I tried using the node executable from the official site (nodejs.org) and that one worked. It seems to be something specific to the Arch Linux package (maybe due to the strip): #90

file on nodejs.org's node:

$ file node 
node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=9db8bab0f2278ee9b1c1809fbf7112bc5cb77187, for GNU/Linux 3.2.0, with debug_info, not stripped, too many notes (256)

file on Arch Linux's node:

$ file /usr/bin/node
/usr/bin/node: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=5ea24a48bb07a833a65830a18719b83890601097, for GNU/Linux 4.4.0, stripped

@efip-ns
Copy link

efip-ns commented Nov 18, 2024

My situation looks related, collector is a Nodejs SEA:

$ file collector
collector: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, 
    interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0f9456b479c15173ce4d2b535d740921348e19a4, 
    for GNU/Linux 3.2.0, with debug_info, not stripped, too many notes (256)

$ ./collector
(node:78487) ExperimentalWarning: Single executable application is an experimental feature and might change at any time
(Use `collector --trace-warnings ...` to show where the warning was created)
[Nest] 78487  - 11/18/2024, 2:02:12 PM     LOG [NestFactory] Starting Nest application...
...

$ strip -o bad.collector collector
strip: bad.collector: section .init lma 0xca6000 adjusted to 0xca7150
strip: bad.collector: section .plt lma 0xca6020 adjusted to 0xca7170
strip: bad.collector: section .text lma 0xca8000 adjusted to 0xca90a0
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment
strip: bad.collector: warning: allocated section `' not in segment

$ file bad.collector
bad.collector: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, 
    interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0f9456b479c15173ce4d2b535d740921348e19a4, 
    for GNU/Linux 3.2.0, stripped

$ ./bad.collector
Segmentation fault (core dumped)

Interestingly:

$ llvm-strip -o good.collector collector
$ file good.collector
good.collector: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, 
    interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0f9456b479c15173ce4d2b535d740921348e19a4, 
    for GNU/Linux 3.2.0, stripped
$ ./good.collector
(node:84920) ExperimentalWarning: Single executable application is an experimental feature and might change at any time
(Use `good.collector --trace-warnings ...` to show where the warning was created)
[Nest] 84920  - 11/18/2024, 2:05:48 PM     LOG [NestFactory] Starting Nest application...

Stripping runs as a part of packing RPM on Rocky Linux but I believe RHEL would behave the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants