MultiMail segfault
Closed this issue · 12 comments
Multimail segfaults when started after asking to edit .mmailrc now.
This is a new build on slackware-current. The build finishes cleanly and the resulting mm looks OK. When I run mm with gdb it says this..
Program received signal SIGSEGV, segmentation fault.
0x00007ffff7f66ab6 in waddch () from /lib64/libncurses.so.6
I am able to run mm from a build I did on slackware 14.2 a few years back. I am not sure what causes this. This binary is available at http://trmb.ca/mm if anyone would like to inspect it, or try to run it on another OS.
Hi @aianson
Multimail segfaults when started after asking to edit .mmailrc now.
This is a new build on slackware-current. The build finishes cleanly and the resulting mm looks OK. When I run mm with gdb it says this..
Program received signal SIGSEGV, segmentation fault.
0x00007ffff7f66ab6 in waddch () from /lib64/libncurses.so.6
At that point, enter info stack and hit enter. That may give you an extra clue.
I am able to run mm from a build I did on slackware 14.2 a few years back. I am not sure what causes this. This binary is available at http://trmb.ca/mm if anyone would like to inspect it, or try to run it on another OS.
It's linking to libraries where you built it. See what happens when I use ldd on Manjaro:
$ ldd ~/Downloads/mm
linux-vdso.so.1 (0x00007ffd0d7cc000)
libncurses.so.6 => not found
libtinfo.so.6 => /usr/lib/libtinfo.so.6 (0x00007f83e5f88000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f83e5d72000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f83e5c2e000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f83e5c13000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f83e5a47000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
Even though I have libncurses installed.
Using the git version of mm, and also the 0.52 release, I can reproduce this on Slackware current, although my Slackware-current is not completely in sync with the current current.
After mm creates the initial ~/.mmailrc, a segfault message is output to the console. After that, running mm again will always result in a segfault immediately. Though curses does get initialized, mm doesn't draw the screen.
Using reset is required to get the terminal back to normal.
$ ldd ./mm
linux-vdso.so.1 (0x00007ffd47907000)
libncurses.so.6 => /lib64/libncurses.so.6 (0x00007f79209a6000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f7920978000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f79207a3000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7920659000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f792063f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7920460000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f7920459000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7920a02000)
Here's some strace output
strace-mm.txt
@aianson the info stack doesn't do much if the binary is stripped. When building, you can use make DEBUG=Y to prevent stripping the debug symbols from the resulting binary.
Using the git version of mm, and also the 0.52 release, I can reproduce this on Slackware current, although my Slackware-current is not completely in sync with the current current.
Thank you for looking at that and confirming. My slackware-current is up to date but I have been seeing this for some time, a year or more only on slackware-current. I have not seen this on debian. My debian is version 10, buster.
So... if I wanted to setup Slackware-current in a VirtualBox to test this, what's the fastest way? I only see ISOs of 14.2.
@wmcbrine There's a link to slackware64-current-install-dvd.iso at https://distrowatch.com/?newsid=11210 and also a "mini" iso, but I'm not sure if that would contain all the development packages you'd need.
@aianson Same here, works on Debian 10, Debian 11 (Bullseye), Manjaro, and OpenSuse Tumbleweed.
So... if I wanted to setup Slackware-current in a VirtualBox to test this, what's the fastest way? I only see ISOs of 14.2.
There are fresh ISO's here..
OK, I can confirm the error. No idea on the cause yet.
It's looking like this happens with almost any C++ program linked with the system [n]curses, although there's some subtlety I haven't pinned down yet. I tested with some of the simple demo programs from PDCurses, recompiling them as C++ -- rain failed immediately, the same as mm; firework actually drew exactly one whole sequence before segfaulting (and this is repeatable). When built as C, the same programs work fine.
I've asked on LQ about it.
In the meantime, I've added the -fanalyzer and -Wextra flag and re-compiled the program. Here's the output in an attached file:
Btw, I was also able to build a C program that uses ncurses, one of mine, and it worked fine.
Thanks for looking at this for me.
Reading GazL's comments on LQ I think he is spot on and the issue is something in slackware-current's libncurses library. I am able to run mm when I change the Makefile to link against ncursesw instead of ncurses.
Thanks for looking at this for me.
Reading GazL's comments on LQ I think he is spot on and the issue is something in slackware-current's libncurses library. I am able to run mm when I change the Makefile to link against ncursesw instead of ncurses.
@aianson I've sent an email to the Slackware folks using the contact info on slackware.com. Also posted the discussion to ##slackware on Libera Chat IRC. So they can decide if it's something that should be changed before Slackware 15.0 is released.
Slackware-current just got an update for ncurses to 6.3 and this issue is not happening anymore. I can build and run mm without making changes to the Makefile so I will close this issue. The issue was not a MultiMail issue but I think an issue in the ncurses slackware-current was using.