| View previous topic :: View next topic |
| Author |
Message |
_j
n00b
Joined: 05 Jan 2018
Posts: 9
|
 Posted: Mon May 28, 2018 9:18 pm Post subject: Squashfs segfaulting (musl) [Solved] |
 |
|
Hi there,
I'm trying to use LXD and when it tries to unpack the image with squashfs it segfaults - I have no idea why and all the kernel options are set as per the wiki article for squashfs. I've also tried debugging with strace and it seems to be a library issue: | Code: | # strace unsquashfs -f -d /var/lib/lxd/storage-pools/default/images/03e9fa4b42a7a176f326c7973632a556d56bd9ef06620b927a44b4349631b4a4_tmp/rootfs -n /var/lib/lxd/images/03e9fa4b42a7a176f326c7973632a556d56bd9ef06620b927a44b4349631b4a4.rootfs
execve("/usr/bin/unsquashfs", ["unsquashfs", "-f", "-d", "/var/lib/lxd/storage-pools/defau"..., "-n", "/var/lib/lxd/images/03e9fa4b42a7"...], 0x7ffdb79cd788 /* 19 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7fa57edc4b48) = 0
set_tid_address(0x7fa57edc4b80) = 4102
open("/etc/ld-musl-x86_64.path", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="/usr/lib/gcc/x86_64-gentoo-linux"..., iov_len=1024}], 2) = 93
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3) = 0
open("/usr/lib/gcc/x86_64-gentoo-linux-musl/7.3.0/libz.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/llvm/5/lib/libz.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0755, st_size=95944, ...}) = 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20$\0\0\0\0\0\0"..., 960) = 960
mmap(NULL, 2195456, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fa57e906000
mmap(0x7fa57eb1c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x16000) = 0x7fa57eb1c000
close(3) = 0
open("/usr/lib/gcc/x86_64-gentoo-linux-musl/7.3.0/liblzma.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/llvm/5/lib/liblzma.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0755, st_size=165424, ...}) = 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P/\0\0\0\0\0\0"..., 960) = 960
mmap(NULL, 2265088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fa57e6dd000
mmap(0x7fa57e904000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x27000) = 0x7fa57e904000
close(3) = 0
open("/usr/lib/gcc/x86_64-gentoo-linux-musl/7.3.0/liblzo2.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/llvm/5/lib/liblzo2.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/liblzo2.so.2", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0755, st_size=140848, ...}) = 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 %\0\0\0\0\0\0"..., 960) = 960
mmap(NULL, 2240512, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fa57e4ba000
mmap(0x7fa57e6db000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x21000) = 0x7fa57e6db000
close(3) = 0
open("/usr/lib/gcc/x86_64-gentoo-linux-musl/7.3.0/liblz4.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/llvm/5/lib/liblz4.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/liblz4.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/liblz4.so.1", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0755, st_size=91696, ...}) = 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0(\0\0\0\0\0\0"..., 960) = 960
mmap(NULL, 2191360, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fa57e2a3000
mmap(0x7fa57e4b8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x15000) = 0x7fa57e4b8000
close(3) = 0
mprotect(0x7fa57eb1c000, 4096, PROT_READ) = 0
mprotect(0x7fa57e904000, 4096, PROT_READ) = 0
mprotect(0x7fa57e6db000, 4096, PROT_READ) = 0
mprotect(0x7fa57e4b8000, 4096, PROT_READ) = 0
mprotect(0x7fa57edc1000, 4096, PROT_READ) = 0
mprotect(0x555d44188000, 4096, PROT_READ) = 0
geteuid() = 0
umask(000) = 022
open("/var/lib/lxd/images/03e9fa4b42a7a176f326c7973632a556d56bd9ef06620b927a44b4349631b4a4.rootfs", O_RDONLY) = 3
lseek(3, 0, SEEK_SET) = 0
read(3, "hsqs\305J\3\0\341\26\f[\0\0\20\0\330\2\0\0\4\0\24\0\300\0\7\0\4\0\0\0"..., 96) = 96
rt_sigprocmask(SIG_BLOCK, [HUP QUIT], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT TERM], [HUP QUIT], 8) = 0
sched_getaffinity(0, 128, [0, 1, 2, 3]) = 8
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=4*1024}) = 0
brk(NULL) = 0x555d4594f000
brk(0x555d45952000) = 0x555d45952000
brk(0x555d45955000) = 0x555d45955000
brk(0x555d4595a000) = 0x555d4595a000
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa57ed40000
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa57ecbf000
rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) = 0
mmap(NULL, 90112, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa57eca9000
mprotect(0x7fa57ecaa000, 86016, PROT_READ|PROT_WRITE) = 0
clone(child_stack=0x7fa57ecbeac8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tidptr=0x7fa57ecbeb20, tls=0x7fa57ecbeae8, child_tidptr=0x7fa57ecbeb20) = 4103
mmap(NULL, 90112, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa57ec93000
mprotect(0x7fa57ec94000, 86016, PROT_READ|PROT_WRITE) = 0
clone(child_stack=0x7fa57eca8ac8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tidptr=0x7fa57eca8b20, tls=0x7fa57eca8ae8, child_tidptr=0x7fa57eca8b20) = 4104
mmap(NULL, 90112, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa57ec7d000
mprotect(0x7fa57ec7e000, 86016, PROT_READ|PROT_WRITE) = 0
clone(child_stack=0x7fa57ec92ac8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tidptr=0x7fa57ec92b20, tls=0x7fa57ec92ae8, child_tidptr=0x7fa57ec92b20) = 4105
mmap(NULL, 90112, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa57ec67000
mprotect(0x7fa57ec68000, 86016, PROT_READ|PROT_WRITE) = 0
clone(child_stack=0x7fa57ec7cac8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tidptr=0x7fa57ec7cb20, tls=0x7fa57ec7cae8, child_tidptr=0x7fa57ec7cb20) = 4106
mmap(NULL, 90112, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa57ec51000
mprotect(0x7fa57ec52000, 86016, PROT_READ|PROT_WRITE) = 0
clone(child_stack=0x7fa57ec66ac8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tidptr=0x7fa57ec66b20, tls=0x7fa57ec66ae8, child_tidptr=0x7fa57ec66b20) = 4107
+++ killed by SIGSEGV +++
Segmentation fault |
Has anyone got a clue to why this is occuring? I'm running amd64 with ~amd64 gcc (7.3.0).
Last edited by _j on Wed May 30, 2018 11:54 am; edited 1 time in total |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue May 29, 2018 6:02 am Post subject: |
|
|
kernel options should be irrelevant for unsquashfs.
Perhaps something in your library is not multithreading safe. Try with option -p 1 |
|
| Back to top |
|
|
_j
n00b
Joined: 05 Jan 2018
Posts: 9
|
| Posted: Tue May 29, 2018 1:42 pm Post subject: |
|
|
| mv wrote: | kernel options should be irrelevant for unsquashfs.
Perhaps something in your library is not multithreading safe. Try with option -p 1 |
Hi mv,
Thank you for the reply (and dbus-free gtk3  )
Unfortunately it still segfaults. I'm at a bit of a loss as to why it is - I may try moving back to gcc 6.4.0 and see if that alleviates the issue.
AFAIK I understand, it looks for the libs in gcc/llvm dirs, finds them in /lib and then ???
~J |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue May 29, 2018 2:09 pm Post subject: |
|
|
| _j wrote: | | AFAIK I understand, it looks for the libs in gcc/llvm dirs, finds them in /lib |
This is probably the usual order of library directories according to your /etc/ld.so.conf. So everything seems OK here.
Everything until the read() (including) seems reasonable as well.
The rest either initiates multiple tasks or is already reacting to a segfault - I am not sure which of both.
In any case, it is not visible where exactly the segfault happens; I would guess in unsquashfs itself and not in some library.
You could try to compile with debugging symbols, and run | Code: | $ gdb --args unsquashfs ...
(gdb) run
...
(gdb) bt |
to get a perhaps more precise location of the segfault.
Note that the segfault might also be caused by the data itself. I am not sure whether the squashmount data file is machine independent. For instance, if the squashfile was produced by a big-endian machine and you try to unsquash it on a low-endian machine (or vice versa) and unsquash was not written very carefully, such a segfault might be "normal". |
|
| Back to top |
|
|
_j
n00b
Joined: 05 Jan 2018
Posts: 9
|
| Posted: Tue May 29, 2018 11:01 pm Post subject: |
|
|
Hi again mv,
I've just got round to using gdb and here is the output:
| Code: | gdb --args unsquashfs -f -d test -n 03e9fa4b42a7a176f326c7973632a556d56bd9ef06620b927a44b4349631b4a4.rootfs
GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-gentoo-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from unsquashfs...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/unsquashfs -f -d test -n 03e9fa4b42a7a176f326c7973632a556d56bd9ef06620b927a44b4349631b4a4.rootfs
[New LWP 11740]
[New LWP 11741]
[New LWP 11742]
[New LWP 11743]
[New LWP 11744]
[New LWP 11745]
[New LWP 11746]
Thread 6 "unsquashfs" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 11744]
0x000055555555c623 in ?? ()
(gdb) bt
#0 0x000055555555c623 in ?? ()
#1 0x00007ffff7dbb93e in ?? () from /lib/ld-musl-x86_64.so.1
#2 0x0000000000000000 in ?? () |
I'm absolutely clueless Is it worth building debugging symbols? i tried recompiling squashfs-tools with gcc 6.4.0 but still the same result.
EDIT: Also tried extracting it with 7z which succeeds. |
|
| Back to top |
|
|
_j
n00b
Joined: 05 Jan 2018
Posts: 9
|
| Posted: Tue May 29, 2018 11:09 pm Post subject: |
|
|
| Also, I'm guessing that it's little-endian since amd64 is? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed May 30, 2018 6:13 am Post subject: |
|
|
It seems task handling cannot be omitted in unsquashfs. Perhaps there is some bug concerning the task implementation in musl. But of course this is only a wild guess: it might also be something completely different.
In any case, for debugging you should use -p 1 to use only 1 task (it seems you have 8 cores, that's why 8 tasks are apparently used initially).
Without debugging symbols, the gdb output is almost useless: Use CFLAGS="-g -ggdb3" FEATURES=nostrip when reemerging squashfs-tools (or rebuild manually with these CFLAGS).
| Code: | #0 0x000055555555c623 in ?? ()
#1 0x00007ffff7dbb93e in ?? () from /lib/ld-musl-x86_64.so.1
#2 0x0000000000000000 in ?? () |
This looks strange, especially the start with #2 0, but it might be related with the multiple tasks.
It is also strange that there is a callback from musl, but again this might be related with task-scheduling.
If you build with debugging symbols, the ?? in #0 might hopefully get resolved: Hopefully, this is where the segfaults actually happens (though not necessarily the place of the bug). In any case, do not forget -p 1. |
|
| Back to top |
|
|
_j
n00b
Joined: 05 Jan 2018
Posts: 9
|
| Posted: Wed May 30, 2018 11:53 am Post subject: |
|
|
| mv wrote: | It seems task handling cannot be omitted in unsquashfs. Perhaps there is some bug concerning the task implementation in musl. But of course this is only a wild guess: it might also be something completely different.
In any case, for debugging you should use -p 1 to use only 1 task (it seems you have 8 cores, that's why 8 tasks are apparently used initially).
Without debugging symbols, the gdb output is almost useless: Use CFLAGS="-g -ggdb3" FEATURES=nostrip when reemerging squashfs-tools (or rebuild manually with these CFLAGS).
| Code: | #0 0x000055555555c623 in ?? ()
#1 0x00007ffff7dbb93e in ?? () from /lib/ld-musl-x86_64.so.1
#2 0x0000000000000000 in ?? () |
This looks strange, especially the start with #2 0, but it might be related with the multiple tasks.
It is also strange that there is a callback from musl, but again this might be related with task-scheduling.
If you build with debugging symbols, the ?? in #0 might hopefully get resolved: Hopefully, this is where the segfaults actually happens (though not necessarily the place of the bug). In any case, do not forget -p 1. |
mv,
I tried that and it complained that "squashfs.c was not found" or something along those lines. Since it's a callback from musl, I did a bit of digging and found this: https://sourceforge.net/p/squashfs/bugs/59/
The problem - "On musl libc the default stack size is 80Kb which is a lot smaller than glibc who allocates 8MB by default."
I'm not sure if this can be included in the portage tree or the musl overlay, but I'll send a bug/PR. Patch is here: https://git.alpinelinux.org/cgit/aports/tree/main/squashfs-tools/vla-overlow.patch
Many thanks for all the help, marking as solved! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed May 30, 2018 5:13 pm Post subject: |
|
|
| _j wrote: | | I'm not sure if this can be included in the portage tree or the musl overlay |
It is now included in the mv overlay: I am afraid that squashfs-tools upstream is quite inactive; the gentoo repository is quite behind, anyway, since squashfs-tools marked no release since 2014 although there were several quite important patches until end of 2017.
The patch you mention is certainly not correct: It makes no sense to call "free" after an endless loop. Either one should allocate and free the temporary space in every loop, or one should not even attempt to free the memory. The latter makes sense if the function is called only once per thread (because allocating/freeing costs time and is perhaps disallowed during multithreading anyway). The patch used now in the mv overlay assumes this. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
