CPod: Segmentation Fault on Arch Linux

CPod version: 1.25.5

Description of the problem: When I try to launch the AppImage, I experience a segmentation fault.

Trying to run the program with gdb yields the following:

GNU gdb (GDB) 8.1.1
Copyright (C) 2018 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
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 CPod-1.25.5-x86_64.AppImage...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/noammac/bin/CPod-1.25.5-x86_64.AppImage 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
process 18886 is executing new program: /usr/bin/bash
1056 1051
process 18886 is executing new program: /tmp/.mount_CPod-19llsUe/app/cumulonimbus
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000a4e5b0 in ?? ()
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) quit

Trying to run the program with LD_DEBUG=libs ./CPod-1.25.5-x86_64.AppImage yields a log so long I had to upload it here.

As you can see, the fault starts immediately after trying to load libnode.so. So, I tried to compile the program myself to see if the error would persist.

When I ran yarn on the repository I was constantly hit with an error, running it in verbose mode showed that it had tried to download node-sass from https://github.com/sass/node-sass/releases/download/v4.5.3/linux-x64-64_binding.node, a URL that doesn’t exist. Removing yarn.lock seemed to solve the problem.

Running yarn start didn’t do anything, so I had to install electron myself and run it on the repository, which has worked well for the time being.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 24 (8 by maintainers)

Most upvoted comments

@z------------- The problem is solved, I tested it with version 1.26.0-pre.

ZeroDot1 on Aug 17, 2018

I managed to create an AppImage that won’t segfault.

WARNING: This is highly experimental, a dependency mess (have I mentioned that I despise node?), and probably not a good idea. On the other hand, it’s sandboxed.

I haven’t tested this on another machine, but here it is anyway.

EDIT: Changed file upload to Mixtape, you may need to change the file name.

Noammac on Aug 16, 2018

Read through the Arch bug report and the electron issue, I’ll try some workaround and report if anything’s of actual use.

EDIT: Looking through some of the linked commits and issues, our safest bet is to wait for glibc2.28-2 to come out of testing, or for the electron linker update.

Noammac on Aug 13, 2018

glibc2.28-4 was released. It should solve the problem. I will report soon if everything is working.

Noammac on Aug 17, 2018

I dare not fork it. What I had done to get this result is unheared of.

Noammac on Aug 16, 2018

Able to consistently reproduce segfault on my virtual Arch Linux. Seems to be a new and known issue: https://github.com/electron/electron/issues/13972, https://github.com/typora/typora-issues/issues/1671, https://bugs.archlinux.org/task/59550.

“It is an upstream bug, which would be fixed in electron/electron#13972”

The workarounds in the links above might be of use for now. The only thing I can do on my end is wait for a fixed version of Electron.

z------------- on Aug 14, 2018

Can confirm this still segfaults.

qixils on Aug 12, 2018

Making the file and directory /etc/gnutls/default-priorities yields different results in strace (command strace -iCfs 100): https://ptpb.pw/Q0_J https://ptpb.pw/dllB

Noammac on Aug 12, 2018

LD_DEBUG=all yields this, on the other hand:

     20482:	binding file /tmp/.mount_CPod-1dXV7SQ/app/libnode.so [0] to /tmp/.mount_CPod-1dXV7SQ/app/libnode.so [0]: normal symbol `nghttp2_session_callbacks_set_on_frame_recv_callback'

Noammac on Aug 12, 2018

Still segfaults. strace error message is stat("/etc/gnutls/default-priorities", 0x7fffb296d170) = -1 ENOENT (No such file or directory)

gdb on bt full:

#0  0x0000000000dbf060 in  ()
#1  0x00007ffff7d83072 in node::http2::Http2Session::Callbacks::Callbacks(bool) ()
    at /tmp/.mount_CPod-1UUWSPd/app/libnode.so
#2  0x00007ffff7d83135 in  () at /tmp/.mount_CPod-1UUWSPd/app/libnode.so
#3  0x00007ffff7fe36da in call_init.part () at /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7fe37da in _dl_init () at /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7fd503a in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in  ()
#7  0x00007fffffffdced in  ()
#8  0x0000000000000000 in  ()

I’ll see if I can find anything else

Noammac on Aug 12, 2018

Here’s an updated build of CPod that includes a newer version of Electron (2.0.0 -> 2.0.7) (as well as some half-finished features I’ve been working on). Please let me know if it solves anything.

z------------- on Aug 12, 2018