You are not logged in.
A compiled software that has been unchanged since July 2013 ran without difficulties on my Arch system until, and including, November 2017. In March 2018, I attempt to run said software again and receive a "Segmentation fault (core dumped)" upon execution. Thus, I conclude that a change in the kernel since fall 2017 renders the software inoperable. How would you suggest me to proceed to get the software up and running again? Here are the details:
The genome assembly software SOAPdenovo2 (https://sourceforge.net/projects/soapde … APdenovo2/) has worked fine on my system until November 2017. Today, it crashes upon execution:
$ ./SOAPdenovo-127mer all
Version 2.04: released on July 13th, 2012
Compile Jul 9 2013 11:57:30
Segmentation fault (core dumped)Since November 2017, I have conducted several system updates via pacman -Syu. Currently, my system hosts the following kernel:
$ uname -r
4.15.11-1-ARCHI assume that downgrading the kernel is the logical way to do this and have, thus, already installed package downgrade, but - truth be told - I am somewhat nervous about fumbling around with the kernel without assistance.
Last edited by Michael Gruenstaeudl (2018-03-22 16:37:12)
Offline
Weird conclusion, to be frank. In fact with the details provided, the kernel would be last thing on my list, and since November wasn't that long ago, the easiest test would be to try out linux-lts (or simply downgrade, as the kernel is one of the most self-contained packages in Arch and is usually the one package safe to keep at old versions without any impact on other software (notwithstanding out of tree kernel modules))
However to really properly look at this, you will first want to check if you can get more details about that coredump.
But on a tangential note, what would first cross my mind are incompatible libs, and since the program seems to be open source my first stop would be compiling an up to date version: https://github.com/aquaskyline/SOAPdenovo2
Offline
Weird conclusion, to be frank. In fact with the details provided, the kernel would be last thing on my list, and since November wasn't that long ago, the easiest test would be to try out linux-lts (or simply downgrade, as the kernel is one of the most self-contained packages in Arch and is usually the one package safe to keep at old versions without any impact on other software (notwithstanding out of tree kernel modules))
It is fully possible that the kernel is completely innocent here. This is why I posted this in the Newbie Corner.
However to really properly look at this, you will first want to check if you can get more details about that coredump.
Here are details about the coredump, but they don't seem to provide more info than informing us that "Program terminated with signal SIGSEGV".
$ coredumpctl gdb 10131
PID: 10131 (SOAPdenovo-127m)
UID: 1000 (michael_science)
GID: 100 (users)
Signal: 11 (SEGV)
Timestamp: Thu 2018-03-22 17:13:10 CET (3min 35s ago)
Command Line: ./SOAPdenovo-127mer all
Executable: /home/michael_science/git/IOGA/exe/SOAPdenovo2-bin-LINUX-generic-r240/SOAPdenovo-127mer
Control Group: /user.slice/user-1000.slice/session-c2.scope
Unit: session-c2.scope
Slice: user-1000.slice
Session: c2
Owner UID: 1000 (michael_science)
Boot ID: XYZ
Machine ID: XYZ
Hostname: XYZ
Storage: /var/lib/systemd/coredump/core.SOAPdenovo-127m.1000.3128869c8bc54ec28b1bf786f90075ba.10131.1521735190000000.lz4
Message: Process 10131 (SOAPdenovo-127m) of user 1000 dumped core.
Stack trace of thread 10131:
#0 0xffffffffff600400 n/a (n/a)
GNU gdb (GDB) 8.1
Reading symbols from /home/michael_science/git/IOGA/exe/SOAPdenovo2-bin-LINUX-generic-r240/SOAPdenovo-127mer...done.
warning: core file may not match specified executable file.
[New LWP 10131]
Core was generated by `./SOAPdenovo-127mer all'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xffffffffff600400 in ?? ()
(gdb) bt
#0 0xffffffffff600400 in ?? ()
#1 0x0000000000523e0d in time ()
#2 0x000000000043a8ed in main ()
(gdb)But on a tangential note, what would first cross my mind are incompatible libs, and since the program seems to be open source my first stop would be compiling an up to date version: https://github.com/aquaskyline/SOAPdenovo2
I am already working on compiling the software from an up-to-date version: https://github.com/aquaskyline/SOAPdenovo2/issues/39. Interestingly, the compilation there fails due to an apparent duplication of a critical library, which was also your first idea. Is there any way I can find out which library is at fault for the segfault with the compiled version (i.e., the issue discussed in this post here)?
Last edited by Michael Gruenstaeudl (2018-03-22 16:35:36)
Offline