Core dump on Linux

[asergi]

I built both fs-utils and NetBSD rump kernel from master branches on a 64-bit Arch Linux install with GCC 4.8.1. The compilation completed successfully but I wasn't able to do anything because always ran into a core dump.

Here's the output of fsu_ls examining the content of a ISO image: https://gist.github.com/asergi/5883320

[anttikantee]

I managed to repeat it, the problem is the call to realpath() on line 248 of fsu_mount.c. I'll try to fix it later today if I have a few spare minutes.

[anttikantee]

Should be fixed now, code was using a homegrown buffer length for realpath().

Thanks for the report!

[asergi]

Thanks, the core dump issue has been fixed. Actually, the fsu_ls output is not really exciting nor yet useful :)

% fsu_ls ~/NetBSD-6.1-amd64.iso -l
?----w---x  69632 611  0  0 Jan  1  1970 .

Anyway, thanks for your work. I watched the video of your talk at FOSDEM and it was really interesting.

[anttikantee]

Yes, I agree it's not supposed to "work" like that. Smells like a syscall compat problem, but I don't have access to a 64bit Arch for debugging. Anyone?

Just to make sure, are you talking about amd64 or something else?

If the problem is not resolved soon, please file a new issue with full details on the host you're using.

[asergi]

Yes, amd64 Arch Linux.

Let me know what you need and I'll file a new issue.

[stacktic]

I have installed arch in a vm (x86_64/gcc 4.8.1/Linux 3.9.8-1) and everything works out of the box.

Do you have anything custom?

[staalmannen]

I also use 64-bit Arch as my working distro (for now). A question: should I update the OBS packages to get this issue resolved and do I also need to update the rump OBS packages? (for AUR, it is automatic since it builds the latest sources).

@anttikantee : perhaps a link to the FOSDEM talk should be in the Rump github README to "hook" some curious visitors?

[anttikantee]

@staalmannen It's not specific to 64bit Arch, it's specific to any builds which are done with -fstack-protector -D_FORTIFY_SOURCE=2 on hosts where PATH_MAX > 1024. That said, it's a potential security problem, so updating the packages at some point might be a good idea. But I'd say wait until the "does not work" problem has been resolved, at least unless you can update the packages very easily. Finally, yea, adding the video link might be a good idea.

@asergi The build output is the most important piece of information. That, and you confirming if it's amd64/x86_64 or not (I don't know if Arch runs on other 64bit platforms).

[asergi]

@anttikantee @stacktic indeed the build is done with -fstack-protector -D_FORTIFY_SOURCE=2. Here's the x86_64/amd64 Arch Linux's default compile flags (from /etc/makepkg.conf):

#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

and here's the compile flags I'm using on my x86_64/amd64 Arch Linux:

CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=core2 -mtune=core2 -O2 -pipe -fstack-protector --param=ssp-buffer-size=4"
CXXFLAGS="$CFLAGS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
MAKEFLAGS="-j3"
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

Hope this helps.

[stacktic]

Using --as-needed in the LDFLAGS makes ld remove the dependency to librumpkern_sys_linux which is used for the syscall compat.

@asergi In your case the struct stat is not converted from the NetBSD format to the Linux one, that is why the output of fsu_ls is a bit odd. To prevent this issue, please remove --as-needed from the compilation options in makepkg.conf and rebuild fs-utils.

@anttikantee the --no-as-needed is added before the --as-needed, we need to find a way to put it after.

[anttikantee]

Well spotted. I see two possibilities: silently strip --as-needed from LDFLAGS or return an error if it's present. I think I slightly prefer the first one, since --as-needed doesn't give any user-visible impact and it's unnecessary for fs-utils and completely incompatible with how rump kernels perform linking internally.

[asergi]

Yeah, it works! Removing --as-needed from LDFLAGS and now everything works as expected.

% fsu_ls ~/NetBSD-6.1-amd64.iso -l               
total 12587
drwxr-xr-x   4 611  0     2048 May 13 04:29 amd64
drwxr-xr-x   2 611  0     6144 May 13 04:14 bin
-r--r--r--   1 611  0    73276 May 13 04:31 boot
-rw-r--r--   1 611  0      551 May 13 04:31 boot.cfg
drwxr-xr-x   2 611  0     2048 May 13 04:31 dev
drwxr-xr-x  26 611  0    12288 May 13 04:31 etc
-r-xr-xr-x   1 611  0     3084 May 13 04:31 install.sh
drwxr-xr-x   2 611  0    10240 May 13 04:15 lib
drwxr-xr-x   3 611  0     2048 May 13 03:52 libdata
drwxr-xr-x   4 611  0     2048 May 13 04:31 libexec
drwxr-xr-x   2 611  0     2048 May 13 03:52 mnt
drwxr-xr-x   2 611  0     2048 May 13 04:31 mnt2
-rw-r--r--   1 611  0  5980792 May 13 04:31 netbsd
drwxr-xr-x   2 611  0    18432 May 13 04:15 sbin
drwxr-xr-x   3 611  0     2048 May 13 04:00 stand
-rwxr-xr-x   1 611  0   195223 May 13 04:31 sysinst
-rwxr-xr-x   1 611  0    32225 May 13 04:31 sysinstmsgs.de
-rwxr-xr-x   1 611  0    31250 May 13 04:31 sysinstmsgs.es
-rwxr-xr-x   1 611  0    31977 May 13 04:31 sysinstmsgs.fr
-rwxr-xr-x   1 611  0    27931 May 13 04:31 sysinstmsgs.pl
drwxr-xr-x   2 611  0     2048 May 13 04:31 targetroot
drwxr-xr-x   2 611  0     2048 May 13 03:52 tmp
drwxr-xr-x   8 611  0     2048 May 13 04:31 usr
drwxr-xr-x   2 611  0     2048 May 13 04:31 var

[anttikantee]

I put LINKER_NO_AS_NEEDED into LDADD instead of LDFLAGS. Seems to work, although I'm quite sure it'll come back to bite at some point. I think the other option is to rewrite LINK.

@asergi can you verify that things now work even if you have -Wl,--as-needed in LDFLAGS?

[asergi]

Just for the record: I've also built fs-utils in a clean 64-bit chroot using Arch Linux's default compile flags but nothing as changed until I applied the @stacktic suggestion. Modifying the LDFLAGS manually or overwriting it via PKGBUILD fixed the issue.

[asergi]

@anttikantee yep, now it works even with -Wl,--as-needed in LDFLAGS. Thank you, guys! Keep up the good work! :)

[anttikantee]

Great! Thanks for the reports!