Segmentation fault (core dumped) is back

Reply

Segmentation fault (core dumped) is back

hypergig
Regular

Plan

Premium

Country
US

 

Operating System

Ubuntu 19.04

 

My Question or Issue

 

Today I received a new update to the spotify linux client

 

spotify-client:amd64 (1:1.1.0.237.g378f6f25-11, 1:1.1.5.153.gf614956d-16)

 

 

After which, spotify would crash immediately after starting up. Starting the client from a terminal yielded the following error

 

Segmentation fault (core dumped)

 

 

After troubleshotting for a while, I noticed the problem stopped happening when I deleted my local config directory

 

rm -rf ~/.config/spotify

 

 

Clearly this isn't a solution so I dug in a little, spelunking through the output from running 

spotify --show-console

One line stood out from the rest

13:00:33.032 W [collection_local_bans_file.cpp:51] bans: could not read local bans file: /home/<me>/.config/spotify/Users/<my account>-user/local_bans.pb

(obvious private stuff redacted)

 

So I checked and I don't have that file. But I do have this file

/home/<me>/.config/spotify/Users/<my account>-user/local-files.bnk 

So I tried deleting it to see what happened and started the spotify client back up and it worked but only from the terminal.  However, after a few more tries, it only worked part of the time :/ So I am not sure what to make of that anymore. 

 

I would be happy to send my logs to someone in engineering if you would like.

 

EDIT

It is totally sporadic. Without fiddling with anything and starting the client works about 1 out of 3 times. 

24 Replies

Re: Segmentation fault (core dumped) is back

kaloshade
Newbie

Im also getting the crash. I ran the same command and piped the output to a file. Uploading the file here. Would just post it but the message cant exceed 20k chars.

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

Same thing here. Tried to post a reply about 6 times yesterday but gave up in the end. 

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

So now it seems to be letting me reply - I'm running Spotify version 1.1.5.153.gf614956d on Debian Buster.

 

It's totally sporadic, the process gets killed by SIGSEGV immediately after a call to 35.186.224.53 when it dies. It seems to go from working to dieing sporadically, in all cases I can see from the logs it connects fone, pulls deltas from playlists etc then gets to [gaia_login_state_observer.cpp:42] received new_connection_id then

 

09:13:09.681 D [gaia_manager.cpp:409            ] GAIA: GaiaManager::stateTransition, kServiceStatusStopped->kServiceStatusRunning
09:13:09.682 D [gaia_manager.cpp:1146           ] GAIA: TIMING(2075049165) GaiaManager::sendHelloHelper
09:13:09.699 D [gaia_manager.cpp:1146           ] GAIA: TIMING(2075049182) GaiaManager::sendHelloHelper
09:13:09.721 I [request_accounting.cpp:416      ] High request latency: https://spclient.wg.spotify.com/metadata took 175 ms
09:13:09.777 I [request_accounting.cpp:416      ] High request latency: https://spclient.wg.spotify.com/ads took 377 ms
09:13:09.777 I [request_accounting.cpp:416      ] High request latency: https://spclient.wg.spotify.com/ads took 377 ms
09:13:09.779 I [request_accounting.cpp:416      ] High request latency: https://spclient.wg.spotify.com/ads took 379 ms
Segmentation fault

Not sure if this isn't a race condition somewhere around connection. It's too random to be something on the machine and it connects and pulls the playlist deltas etc without fail every time it starts regarless of whether it segfaults or not. 

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

base64 encoded my reply to get past this ridiculous forum filtering 

 

 

U28gbm93IGl0IHNlZW1zIHRvIGJlIGxldHRpbmcgbWUgcmVwbHkgLSBJJ20gcnVubmluZ8KgU3Bv
dGlmeSB2ZXJzaW9uIDEuMS41LjE1My5nZjYxNDk1NmQgb24gRGViaWFuIC4KCgoKSXQncyB0b3Rh
bGx5IHNwb3JhZGljLCB0aGUgcHJvY2VzcyBnZXRzIGtpbGxlZCBieSBTSUdTRUdWIGltbWVkaWF0
ZWx5IGFmdGVyIGEgY2FsbCB0b8KgMzUuMTg2LjIyNC41MyB3aGVuIGl0IGRpZXMuIEl0IHNlZW1z
IHRvIGdvIGZyb20gd29ya2luZyB0byBkaWVpbmcgc3BvcmFkaWNhbGx5LCBpbiBhbGwgY2FzZXMg
SSBjYW4gc2VlIGZyb20gdGhlIGxvZ3MgaXQgY29ubmVjdHMgZm9uZSwgcHVsbHMgZGVsdGFzIGZy
b20gcGxheWxpc3RzIGV0YyB0aGVuIGdldHMgdG/CoFtnYWlhX2xvZ2luX3N0YXRlX29ic2VydmVy
LmNwcDo0Ml0gcmVjZWl2ZWQgbmV3X2Nvbm5lY3Rpb25faWQgdGhlbgoKCgowOToxMzowOS42ODEg
RCBbZ2FpYV9tYW5hZ2VyLmNwcDo0MDkgICAgICAgICAgICBdIEdBSUE6IEdhaWFNYW5hZ2VyOjpz
dGF0ZVRyYW5zaXRpb24sIGtTZXJ2aWNlU3RhdHVzU3RvcHBlZC0+a1NlcnZpY2VTdGF0dXNSdW5u
aW5nCjA5OjEzOjA5LjY4MiBEIFtnYWlhX21hbmFnZXIuY3BwOjExNDYgICAgICAgICAgIF0gR0FJ
QTogVElNSU5HKDIwNzUwNDkxNjUpIEdhaWFNYW5hZ2VyOjpzZW5kSGVsbG9IZWxwZXIKMDk6MTM6
MDkuNjk5IEQgW2dhaWFfbWFuYWdlci5jcHA6MTE0NiAgICAgICAgICAgXSBHQUlBOiBUSU1JTkco
MjA3NTA0OTE4MikgR2FpYU1hbmFnZXI6OnNlbmRIZWxsb0hlbHBlcgowOToxMzowOS43MjEgSSBb
cmVxdWVzdF9hY2NvdW50aW5nLmNwcDo0MTYgICAgICBdIEhpZ2ggcmVxdWVzdCBsYXRlbmN5OiBo
dHRwczovL3NwY2xpZW50LndnLnNwb3RpZnkuY29tL21ldGFkYXRhIHRvb2sgMTc1IG1zCjA5OjEz
OjA5Ljc3NyBJIFtyZXF1ZXN0X2FjY291bnRpbmcuY3BwOjQxNiAgICAgIF0gSGlnaCByZXF1ZXN0
IGxhdGVuY3k6IGh0dHBzOi8vc3BjbGllbnQud2cuc3BvdGlmeS5jb20vYWRzIHRvb2sgMzc3IG1z
CjA5OjEzOjA5Ljc3NyBJIFtyZXF1ZXN0X2FjY291bnRpbmcuY3BwOjQxNiAgICAgIF0gSGlnaCBy
ZXF1ZXN0IGxhdGVuY3k6IGh0dHBzOi8vc3BjbGllbnQud2cuc3BvdGlmeS5jb20vYWRzIHRvb2sg
Mzc3IG1zCjA5OjEzOjA5Ljc3OSBJIFtyZXF1ZXN0X2FjY291bnRpbmcuY3BwOjQxNiAgICAgIF0g
SGlnaCByZXF1ZXN0IGxhdGVuY3k6IGh0dHBzOi8vc3BjbGllbnQud2cuc3BvdGlmeS5jb20vYWRz
IHRvb2sgMzc5IG1zClNlZ21lbnRhdGlvbiBmYXVsdApOb3Qgc3VyZSBpZiB0aGlzIGlzbid0IGEg
cmFjZSBjb25kaXRpb24gc29tZXdoZXJlIGFyb3VuZCBjb25uZWN0aW9uLiBJdCdzIHRvbyByYW5k
b20gdG8gYmUgc29tZXRoaW5nIG9uIHRoZSBtYWNoaW5lIGFuZCBpdCBjb25uZWN0cyBhbmQgcHVs
bHMgdGhlIHBsYXlsaXN0IGRlbHRhcyBldGMgd2l0aG91dCBmYWlsIGV2ZXJ5IHRpbWUgaXQgc3Rh
cnRzIHJlZ2FybGVzcyBvZiB3aGV0aGVyIGl0IHNlZ2ZhdWx0cyBvciBub3QuwqAK

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

base64-ed again but this is a log snippet from this morning when the client successfully loads.

 

 

b2sgc28gc25pcHBldCBmcm9tIHdoZW4gdGhlIGNsaWVudCBsb2FkcyBzdWNjZXNzZnVsbHkgdGhpcyBtb3JuaW5nLi4uCgoKMDk6MzQ6MDEuMjg1IEUgW3B1YnN1Yl9zdWJzY3JpcHRpb24uY3BwOjU5MSAgICAgXSBhcTogTFdTIGdvdCBMV1NfQ0FMTEJBQ0tfQ0xJRU5UX1dSSVRFQUJMRQowOTozNDowMS4yODUgRSBbcHVic3ViX3N1YnNjcmlwdGlvbi5jcHA6NTkxICAgICBdIGFxOiBMV1MgZ290IExXU19DQUxMQkFDS19DTElFTlRfV1JJVEVBQkxFCjA5OjM0OjAxLjI5MCBFIFtnYWlhX2xvZ2luX3N0YXRlX29ic2VydmVyLmNwcDo0Ml0gcmVjZWl2ZWQgbmV3X2Nvbm5lY3Rpb25faWQgPDxSRURBQ1RFRD4+IC0gc3RhcnRpbmcKCjA5OjM0OjAxLjI5MCBEIFtnYWlhX21hbmFnZXIuY3BwOjQwOSAgICAgICAgICAgIF0gR0FJQTogR2FpYU1hbmFnZXI6OnN0YXRlVHJhbnNpdGlvbiwga1NlcnZpY2VTdGF0dXNTdG9wcGVkLT5rU2VydmljZVN0YXR1c1J1bm5pbmcKMDk6MzQ6MDEuMjkwIEQgW2dhaWFfbWFuYWdlci5jcHA6MTE0NiAgICAgICAgICAgXSBHQUlBOiBUSU1JTkcoMjA3NjMwMDc3NCkgR2FpYU1hbmFnZXI6OnNlbmRIZWxsb0hlbHBlcgowOTozNDowMS4zMDIgRSBbcHVic3ViX3N1YnNjcmlwdGlvbi5jcHA6NTkxICAgICBdIGFxOiBMV1MgZ290IExXU19DQUxMQkFDS19DTElFTlRfUkVDRUlWRV9QT05HCjA5OjM0OjAxLjMzMyBEIFtnYWlhX21hbmFnZXIuY3BwOjExNDYgICAgICAgICAgIF0gR0FJQTogVElNSU5HKDIwNzYzMDA4MTYpIEdhaWFNYW5hZ2VyOjpzZW5kSGVsbG9IZWxwZXIKMDk6MzQ6MDEuMzM0IEkgW3JlcXVlc3RfYWNjb3VudGluZy5jcHA6NDE2ICAgICAgXSBIaWdoIHJlcXVlc3QgbGF0ZW5jeTogaHR0cHM6Ly9zcGNsaWVudC53Zy5zcG90aWZ5LmNvbS9hZHMgdG9vayAyNjMgbXMKMDk6MzQ6MDEuMzM0IEkgW3JlcXVlc3RfYWNjb3VudGluZy5jcHA6NDE2ICAgICAgXSBIaWdoIHJlcXVlc3QgbGF0ZW5jeTogaHR0cHM6Ly9zcGNsaWVudC53Zy5zcG90aWZ5LmNvbS9hZHMgdG9vayAyNjMgbXMKMDk6MzQ6MDEuMzM1IEkgW3JlcXVlc3RfYWNjb3VudGluZy5jcHA6NDE2ICAgICAgXSBIaWdoIHJlcXVlc3QgbGF0ZW5jeTogaHR0cHM6Ly9zcGNsaWVudC53Zy5zcG90aWZ5LmNvbS9hZHMgdG9vayAyNjQgbXMKMDk6MzQ6MDEuMzQwIEQgW2dhaWFfbWFuYWdlci5jcHA6MTE0NiAgICAgICAgICAgXSBHQUlBOiBUSU1JTkcoMjA3NjMwMDgyMykgR2FpYU1hbmFnZXI6OnNlbmRIZWxsb0hlbHBlcgoKV09VTEQgTk9STUFMTFkgU0VHRkFVTFQgSEVSRSBXSEVOIEZBSUxJTkcKCgowOTozNDowMS42NDcgSSBbcmVxdWVzdF9hY2NvdW50aW5nLmNwcDo0MTYgICAgICBdIEhpZ2ggcmVxdWVzdCBsYXRlbmN5OiBobTovL3ZhbmlsbGEvdjEgdG9vayAyMDkgbXMKMDk6MzQ6MDIuNzExIEkgW3N0YXJ0dXBfdGltZV9sb2dnZXIuY3BwOjQzNCAgICAgXSB1c2FibGVfc3RhdGU6IHByb2Nlc3Nfc3RhcnQ6MCxhcHBfaW5pdDo1MCxjb3JlX2luaXQ6NzksemxpbmtfbG9hZF9zdGFydDo4Nyxjb3JlX2luaXRfZG9uZToxMDEsaW5pdGlhbF9hcF9jb25uZWN0aW9uOjEwOCxpbml0aWFsX2FwX2Nvbm5lY3Rpb25fZG9uZTo3ODMsaW5pdGlhbF92aWV3X2xvYWRfc3RhcnQ6MTQ1MSx1c2FibGVfc3RhdGU6Mjc0NQowOTozNDowMi43MzcgNSBbcGxheWxpc3RfYmVfcGw0X2NvbnRleHQuY3BwOjk5ICBdIFtzcG90aWZ5OnVzZXI6c3BvdGlmeTpwbGF5bGlzdDpSRURBQ1RFRFJFREFDVEVEUkVEQUNUXSBDcmVhdGluZyBjb250ZXh0CjA5OjM0OjAyLjczNyA1IFtwbGF5bGlzdF9iYWNrZW5kLmNwcDoxNjEgICAgICAgIF0gUGxheWxpc3RCYWNrZW5kTWFuYWdlcjo6cmVzeW5jRGVsYXllZFBsYXlsaXN0Tm93KHNwb3RpZnk6dXNlcjpzcG90aWZ5OnBsYXlsaXN0OjM3UkVEQUNURURSRURBQ1RFRFJFREEpCjA5OjM0OjAyLjczOCA1IFtwbGF5bGlzdF9iZV9wbDRfY29udGV4dC5jcHA6OTkgIF0gW3Nwb3RpZnk6dXNlcjpzcG90aWZ5OnBsYXlsaXN0OlJFREFDVEVEUkVEQUNURURSRURBQ1RdIENyZWF0aW5nIGNvbnRleHQKMDk6MzQ6MDIuNzM4IDUgW3BsYXlsaXN0X2JhY2tlbmQuY3BwOjE2MSAgICAgICAgXSBQbGF5bGlzdEJhY2tlbmRNYW5hZ2VyOjpyZXN5bmNEZWxheWVkUGxheWxpc3ROb3coc3BvdGlmeTp1c2VyOnNwb3RpZnk6cGxheWxpc3Q6UkVEQUNURURSRURBQ1RFRFJFREFDVCkKMDk6MzQ6MDIuNzM5IDUgW3BsYXlsaXN0X2JlX3BsNF9jb250ZXh0LmNwcDo5OSAgXSBbc3BvdGlmeTp1c2VyOnNwb3RpZnk6cGxheWxpc3Q6UkVEQUNURURSRURBQ1RFRFJFREFDVF0gQ3JlYXRpbmcgY29udGV4dAowOTozNDowMi43MzkgNSBbcGxheWxpc3RfYmFja2VuZC5jcHA6MTYxICAgICAgICBdIFBsYXlsaXN0QmFja2VuZE1hbmFnZXI6OnJlc3luY0RlbGF5ZWRQbGF5bGlzdE5vdyhzcG90aWZ5OnVzZXI6c3BvdGlmeTpwbGF5bGlzdDpSRURBQ1RFRFJFREFDVEVEUkVEQUNURQoKCkNvbnRpbnVlcyB0byBsb2FkIHByb3Blcmx5IGZyb20gaGVyZS4K

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

also the client seems to be linked against libcef.so which isn't a dependency of the debian package (isn't available on my machine)...

 

$ ldd /usr/bin/spotify | grep 'not found'
libcef.so => not found

Re: Segmentation fault (core dumped) is back

hypergig
Regular

I may never stop laughing...

 


@thereal_rjf wrote:

base64 encoded my reply to get past this ridiculous forum filtering 

 

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

sorry - got distracted by work, lol....

 

So libsef.so obviously is on the system at /usr/share/spotify/libcef.so so can be ignored - it's just not in the path of my shell.

 

Turned on core dumping, from what I can gather the backtrace at a segfault is sat with libcurl which ties in to what I am seeing, i.e. if you're not connected to the Internet / going through an ssl proxy which isn't working properly - it starts everytime...

 

(gdb) bt
#0  0x00007fabd03ab7a1 in  () at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#1  0x00007fabd038d847 in  () at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#2  0x00007fabd038da26 in  () at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#3  0x00007fabd03c88f2 in  () at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#4  0x00007fabd039446b in  () at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#5  0x00007fabd03983fc in  () at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#6  0x00007fabd03a9aef in  () at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#7  0x00007fabd03aaf91 in curl_multi_perform ()
    at /lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#8  0x0000000003d092f4 in  ()
#9  0x00000000041ddd8c in  ()
#10 0x00007fabc77a1fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#11 0x00007fabc6b9382f in epoll_wait
    (epfd=1920976640, events=0x1, maxevents=1920964832, timeout=0)
    at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#12 0x0000000000000000 in  ()

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

$ ltrace -ttt -T -f -s4096 -l libcurl-gnutls.so.4 spotify

 

snip
[pid 27058] 1561132340.883868 spotify->curl_easy_setopt(0x7fb55c7fece0, 60, 0, 0) = 0 <0
.001778>
[pid 27064] 1561132340.885808 <... curl_multi_wait resumed> ) = 0 <0.102711>
[pid 27064] 1561132340.885985 spotify->curl_multi_add_handle(0x7fb544000b50, 0x7fb55c7fe
ce0, 0x7fb55c011ed0, 0) = 0 <0.002662>
[pid 27064] 1561132340.888752 spotify->curl_multi_perform(0x7fb544000b50, 0x7fb561ff94c8
, 0x7fb55c011fa0, 0 <unfinished ...>
[pid 27064] 1561132340.892539 libcurl-gnutls.so.4->curl_url_cleanup(0, 0x7fb5b74dcb60, 0
x7fb54497db58, 0x7fb54497db38) = 0 <0.001924>
[pid 27064] 1561132340.894534 libcurl-gnutls.so.4->curl_url(0, 0x7fb5b74dcb60, 0x7fb5449
7db58, 0x7fb54497db38) = 0x7fb5448973e0 <0.001493>
[pid 27064] 1561132340.896078 libcurl-gnutls.so.4->curl_url_set(0x7fb5448973e0, 0, 0x7fb
53872db20, 520 <unfinished ...>
[pid 27064] 1561132340.898519 libcurl-gnutls.so.4->curl_url(115, 0, 8, 512) = 0x7fb54430
9360 <0.001710>
[pid 27064] 1561132340.900326 <... curl_url_set resumed> ) = 0 <0.004225>
[pid 27064] 1561132340.900364 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 1, 0x7fb
55c8003d0, 0) = 0 <0.001549>
[pid 27064] 1561132340.902030 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 2, 0x7fb
55c8003e8, 64) = 11 <0.002745>
[pid 27064] 1561132340.905055 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 3, 0x7fb
55c8003f0, 64) = 12 <0.002562>
[pid 27064] 1561132340.908067 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 4, 0x7fb
55c8003f8, 64) = 13 <0.001975>
[pid 27064] 1561132340.910088 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 5, 0x7fb
55c8003d8, 0) = 0 <0.001550>
[pid 27064] 1561132340.911745 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 7, 0x7fb
55c800400, 0) = 0 <0.001293>
[pid 27064] 1561132340.913108 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 6, 0x7fb
55c8003e0, 1 <unfinished ...>
[pid 27064] 1561132340.914309 libcurl-gnutls.so.4->curl_msnprintf(0x7fb561ff91e1, 7, 0x7
fb5b75331e0, 443 <unfinished ...>
[pid 27064] 1561132340.915922 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fb561ff91e1, 7, 0x
7fb5b75331e0, 0x7fb561ff90d0) = 3 <0.001929>
[pid 27064] 1561132340.918227 <... curl_msnprintf resumed> ) = 3 <0.003880>
[pid 27064] 1561132340.918831 <... curl_url_get resumed> ) = 0 <0.005675>
[pid 27064] 1561132340.918885 libcurl-gnutls.so.4->curl_url_get(0x7fb5448973e0, 8, 0x7fb
55c800408, 0) = 0 <0.002921>
[pid 27064] 1561132340.921917 libcurl-gnutls.so.4->curl_getenv(0x7fb5b752c3d8, 0x7fb5441
617e0, 24, 0x7fb544000020) = 0 <0.003185>
[pid 27064] 1561132340.925528 libcurl-gnutls.so.4->curl_getenv(0x7fb5b752c3e1, 0x7fb5441
617e0, 0x7fb5b752c3d8, 24) = 0 <0.001919>
[pid 27064] 1561132340.927525 libcurl-gnutls.so.4->curl_getenv(0x7fb561ff92e0, 0x7fb5441
617e0, 0x7fb5b752c3e1, 1) = 0 <0.001928>
[pid 27064] 1561132340.929534 libcurl-gnutls.so.4->curl_getenv(0x7fb561ff92e0, 0x7fb561f
f92e0, 0xffffff9f, 32) = 0 <0.001743>
[pid 27064] 1561132340.931361 libcurl-gnutls.so.4->curl_getenv(0x7fb5b752c3ea, 0x7fb561f
f92e0, 0x7fb561ff92e0, 32) = 0 <0.001537>
[pid 27064] 1561132340.933036 libcurl-gnutls.so.4->curl_getenv(0x7fb5b752c3f4, 0x7fb561ff92e0, 0x7fb5b752c3ea, 10) = 0 <0.002303>
[pid 27064] 1561132340.935449 libcurl-gnutls.so.4->curl_msnprintf(0x7fb561ff9180, 128, 0x7fb5b7533b0a, 443 <unfinished ...>
[pid 27064] 1561132340.938344 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fb561ff9180, 128,
0x7fb5b7533b0a, 0x7fb561ff90a0) = 26 <0.003683>
[pid 27064] 1561132340.942240 <... curl_msnprintf resumed> ) = 26 <0.006762>
[pid 27064] 1561132340.942519 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fb561ff88e0, 2049, 0x7fb5b7534588, 0x7fb561ff88c8) = 53 <0.001891>
[pid 27064] 1561132340.944521 --- SIGSEGV (Segmentation fault) ---
[pid 27063] 1561132340.944715 +++ killed by SIGSEGV +++
[pid 27097] 1561132340.944730 +++ killed by SIGSEGV +++
[pid 27058] 1561132340.944743 +++ killed by SIGSEGV +++
[pid 27057] 1561132340.944755 +++ killed by SIGSEGV +++
snip

 

segfaults a lot less often when running under ltrace which smells of race condition somewhere. someone with more clue might be of use now :) 

SUGGESTED POSTS