Segmentation fault (core dumped) is back

Solved!
Reply

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

actually that seems to be the problem...

 

I've run spotify multiple times and saved the ltrace output, on all good runs with no segment faults the curl_mvsnprintf call has a maximum maxlength size of like 256.

 

on EVERY segfault run it has a 2049 maxlength without fail just before it seg faults, such as

 

[pid 27749] 1561132996.706568 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fd250b808e0, 2049, 0x7fd29ced0588, 0x7fd250b808c8) = 53 <0.002874>

Re: Segmentation fault (core dumped) is back

treepleks
Casual Listener

Same here with Ubuntu 19.04. I could not get spotify to run and always got the SIGSEGV until I ran it through ltrace. Here, no SIGSEGV but a back window with no output, even after a 10 minutes wait. So, yes possibly a race condition.

 

To add to the list of ltrace/strace, this is what valgrind says. Looks like the code jumps somewhere it should not.

 

==19000== Memcheck, a memory error detector
==19000== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19000== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==19000== Command: spotify --show-console
==19000==
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x61 0xC1 0x4 0xF 0x82 0xA1 0xF6
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F3A
vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0
==19000== valgrind: Unrecognised instruction at address 0x41c5ccb.
==19000== at 0x41C5CCB: ??? (in /usr/share/spotify/spotify)
==19000== by 0x22836FC: ??? (in /usr/share/spotify/spotify)
==19000== by 0x41C0DB0: ??? (in /usr/share/spotify/spotify)
==19000== by 0x41C0B39: ??? (in /usr/share/spotify/spotify)
==19000== by 0x38FD489: ??? (in /usr/share/spotify/spotify)
==19000== by 0x38FD3E4: ??? (in /usr/share/spotify/spotify)
==19000== by 0x38FADCF: ??? (in /usr/share/spotify/spotify)
==19000== by 0x38FAB7D: ??? (in /usr/share/spotify/spotify)
==19000== by 0x38FABE7: ??? (in /usr/share/spotify/spotify)
==19000== by 0x421055C: ??? (in /usr/share/spotify/spotify)
==19000== by 0x4673B1F: ??? (in /lib/x86_64-linux-gnu/ld-2.29.so)
==19000== Your program just tried to execute an instruction that Valgrind
==19000== did not recognise. There are two possible reasons for this.
==19000== 1. Your program has a bug and erroneously jumped to a non-code
==19000== location. If you are running Memcheck and you just saw a
==19000== warning about a bad jump, it's probably your program's fault.
==19000== 2. The instruction is legitimate but Valgrind doesn't handle it,
==19000== i.e. it's Valgrind's fault. If you think this is the case or
==19000== you are not sure, please let us know and we'll try to fix it.
==19000== Either way, Valgrind will now raise a SIGILL signal which will
==19000== probably kill your program.

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

Yeah, looks like it's either a bad pointer being passed in to curl's  buffer location or something, I don't really know what I'm on about so take it with a pinch of salt but my guess is that it's probably a bug with threading - how the app is using curl, by the looks of it.

 

Most of the segfault reports I see on line seem to be due to threads trying operations on the same handles etc. 

 

https://curl.haxx.se/libcurl/c/libcurl-tutorial.html#Multi-threading

 

https://curl.haxx.se/libcurl/c/threadsafe.html

 

Seems that it's always crashing out in the same way when it happens, which is intermittent but affected by ltrace (less likely to segfault if tracing without filtering for the curl lib) so perhaps a bit less racey when running. The maxlength size_t is always topped out at 2049 and there's no such calls of that size to the curl gnutls lib when it runs properly, so probably something being modified by another thread.

 

 

Does seem odd though. Interestingly, there's an SSL cert always read in by Spotify which is exactly 2049 in length. 

 

23867 1561368755.293945 <... SYS_read resumed> , "-----BEGIN CERTIFICATE-----\nMIIFvTCCA6WgAwIBAgIITxvUL1S7L0swDQYJKoZIhvcNAQEFBQAwRzELMAkGA1UE\nBhMCQ0gxFTATBgNVBAoTDFN3a
XNzU2lnbiBBRzEhMB8GA1UEAxMYU3dpc3NTaWdu\nIFNpbHZlciBDQSAtIEcyMB4XDTA2MTAyNTA4MzI0NloXDTM2MTAyNTA4MzI0Nlow\nRzELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEhMB8GA1UEAxM
Y\nU3dpc3NTaWduIFNpbHZlciBDQSAtIEcyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A\nMIICCgKCAgEAxPGHf9N4Mfc4yfjDmUO8x/e8N+dOcbpLj6VzHVxumK4DV644N0Mv\nFz0fyM5oEMF4rhkDKxD6LHmD9ui5aLlV8gR
Epzn5/ASLHvGiTSf5YXu6t+WiE7br\nYT7QbNHm+/pe7R20nqA1W6GSy/BJkv6FCgU+5tkL4k+73JU3/JHpMjUi0R86TieF\nnbAVlDLaYQ1HTWBCrpJH6INaUFjpiou5XaHc3ZlKHzZnu0jkg7Y360g6rw9njxcH\n6ATK72o
xh9TAtvmUcXtnZLi2kUpCe2UuMGoM9ZDulebyzYLs2aFK7PayS+VFheZt\neJMELpyCbTapxDFkH4aDCyr0NQp4yVXPQbBH6TCfmb5hqAaEuSh6XzjZG6k4sIN/\nc8HDO0gqgg8hm7jMqDXDhBuDsz6+pJVpATqJAHgE2cn0m
RmrVn5bi4Y5FZGkECwJ\nMoBgs5PAKrYYC51+jUnyEEp/+dVGLxmSo5mnJqy7jDzmDrxHB9xzUfFwZC8I+bRH\nHTBsROopN4WSaGa8gzj+ezku01DwH/teYLappvonQfGbGHLy9YR0SslnxFSuSGTf\njNFusB3hB48IHpmcc
elM2KX3RxIfdNFRnobzwqIjQAtz20um53MGj
MGg6cFZrEb6\n5i/4z3GcRm25xBWNOHkDRUjvxF3XCO6HOSKGsg0PWEP3calILv3q1h8CAwEAAaOB\nrDCBqTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU\nF6DNweRBtjpbO8tFnb0cwpj6h
lgwHwYDVR0jBBgwFoAUF6DNweRBtjpbO8tFnb0c\nwpj6hlgwRgYDVR0gBD8wPTA7BglghXQBWQEDAQEwLjAsBggrBgEFBQcCARYgaHR0\ncDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS8wDQYJKoZIhvcNAQEFBQADggI
B\nAHPGgeAn0i0P4JUw4ppBf1AsX19iYamGamkYDHRJ1l2E6kFSGG9YrVBWIGrGvShp\nWJHckRE1qTodvBqlYJ7YH39FkWnZfrt4csEGDyrOj4VwYaygzQu4OSlWhDJOhrs9\nxCrZ1x9y7v5RoSJBsXECYxqCsGKrXlcSH9/
L3XWgwF15kIwb4FDm3jH+mHtwX6WQ\n2K34ArZv02DdQEsixT2tOnqfGhpHkXkzuoLcMmkDlm4fS/Bx/uNncqCxv1yL5PqZ\nIseEuRuNI5c/7SXgz2W79WEE790eslpBIlqhn10s6FvJbakMDHiqYMZWjwFaDGi8\naRl5xB9
+lwW/xekkUV7U1UtT7dkjWjYDZaPBA61BMPNGG4WQr2W11bHkFlt4dR2X\nem1ZqSqPe97Dh4kQmUlzeMg9vVE1dCrV8X5pGyq7O70luJpaPXJhkGaH7gzWTdQR\ndAtq/gsD/KNVV4n+SsuuWxcFyPKNIzFTONItaj+CuY0Ia
vdeQXRuwxF+B6wpYJE/\nOMpXEA29MC/HpeZBoNquBYeaoKRlbEwJDIm6uNO5wJOKMPqN5ZprFQFOZ6raYlY+\nhAhm0sQ2fac+EPyI4NSA5QC9qvNOBqN6avlicuMJT+ubDgEj8Z+7fNzcbBGXJbLy\ntGMU0gYqZ4yD9c7qB
9iaah7s5Aq7KkzrCWA5zspi2C5u\n-----END CERTIFICATE-----\n", 4096) = 2049 <0.000026>

 

Which is 

 

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 5700383053117599563 (0x4f1bd42f54bb2f4b)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = CH, O = SwissSign AG, CN = SwissSign Silver CA - G2
        Validity
            Not Before: Oct 25 08:32:46 2006 GMT
            Not After : Oct 25 08:32:46 2036 GMT
        Subject: C = CH, O = SwissSign AG, CN = SwissSign Silver CA - G2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
...

 

I'm wondering whether somehow this is where the 2049 size_t is comming from, passed into curl_mvsnprintf before it's segfaulting. I've tested it again and again and the biggest size_t passed to curl_mvsnprintf normally is 256 when everything is working properly. 

 

 

When it segfaults there's the reado of that ssl cert, two seconds later there's the curl mvsnprintf with the same size_t and segfault...

 

 

23867 1561368755.293945 <... SYS_read resumed> , "-----BEGIN CERTIFICATE-----\nMIIFvTCCA6WgAwIBAgIITxvUL1S7L0swDQYJKoZIhvcNAQEFBQAwRzELMAkGA1UE\nBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEhMB8GA1UEAxMYU3dpc3NTaWdu\nIFNpbHZlciBDQSAtIEcyMB4XDTA2MTAyNTA4MzI0NloXDTM2MTAyNTA4MzI0Nlow\nRzELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEhMB8GA1UEAxMY\nU3dpc3NTaWduIFNpbHZlciBDQSAtIEcyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A\nMIICCgKCAgEAxPGHf9N4Mfc4yfjDmUO8x/e8N+dOcbpLj6VzHVxumK4DV644N0Mv\nFz0fyM5oEMF4rhkDKxD6LHmD9ui5aLlV8gREpzn5/ASLHvGiTSf5YXu6t+WiE7br\nYT7QbNHm+/pe7R20nqA1W6GSy/BJkv6FCgU+5tkL4k+73JU3/JHpMjUi0R86TieF\nnbAVlDLaYQ1HTWBCrpJH6INaUFjpiou5XaHc3ZlKHzZnu0jkg7Y360g6rw9njxcH\n6ATK72oxh9TAtvmUcXtnZLi2kUpCe2UuMGoM9ZDulebyzYLs2aFK7PayS+VFheZt\neJMELpyCbTapxDFkH4aDCyr0NQp4yVXPQbBH6TCfmb5hqAaEuSh6XzjZG6k4sIN/\nc8HDO0gqgg8hm7jMqDXDhBuDsz6+pJVpATqJAHgE2cn0mRmrVn5bi4Y5FZGkECwJ\nMoBgs5PAKrYYC51+jUnyEEp/+dVGLxmSo5mnJqy7jDzmDrxHB9xzUfFwZC8I+bRH\nHTBsROopN4WSaGa8gzj+ezku01DwH/teYLappvonQfGbGHLy9YR0SslnxFSuSGTf\njNFusB3hB48IHpmccelM2KX3RxIfdNFRnobzwqIjQAtz20um53MGjMGg6cFZrEb6\n5i/4z3GcRm25xBWNOHkDRUjvxF3XCO6HOSKGsg0PWEP3calILv3q1h8CAwEAAaOB\nrDCBqTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU\nF6DNweRBtjpbO8tFnb0cwpj6hlgwHwYDVR0jBBgwFoAUF6DNweRBtjpbO8tFnb0c\nwpj6hlgwRgYDVR0gBD8wPTA7BglghXQBWQEDAQEwLjAsBggrBgEFBQcCARYgaHR0\ncDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS8wDQYJKoZIhvcNAQEFBQADggIB\nAHPGgeAn0i0P4JUw4ppBf1AsX19iYamGamkYDHRJ1l2E6kFSGG9YrVBWIGrGvShp\nWJHckRE1qTodvBqlYJ7YH39FkWnZfrt4csEGDyrOj4VwYaygzQu4OSlWhDJOhrs9\nxCrZ1x9y7v5RoSJBsXECYxqCsGKrXlcSH9/L3XWgwF15kIwb4FDm3jH+mHtwX6WQ\n2K34ArZv02DdQEsixT2tOnqfGhpHkXkzuoLcMmkDlm4fS/Bx/uNncqCxv1yL5PqZ\nIseEuRuNI5c/7SXgz2W79WEE790eslpBIlqhn10s6FvJbakMDHiqYMZWjwFaDGi8\naRl5xB9+lwW/xekkUV7U1UtT7dkjWjYDZaPBA61BMPNGG4WQr2W11bHkFlt4dR2X\nem1ZqSqPe97Dh4kQmUlzeMg9vVE1dCrV8X5pGyq7O70luJpaPXJhkGaH7gzWTdQR\ndAtq/gsD/KNVV4n+SsuuWxcFyPKNIzFTONItaj+CuY0IavdeQXRuwxF+B6wpYJE/\nOMpXEA29MC/HpeZBoNquBYeaoKRlbEwJDIm6uNO5wJOKMPqN5ZprFQFOZ6raYlY+\nhAhm0sQ2fac+EPyI4NSA5QC9qvNOBqN6avlicuMJT+ubDgEj8Z+7fNzcbBGXJbLy\ntGMU0gYqZ4yD9c7qB9iaah7s5Aq7KkzrCWA5zspi2C5u\n-----END CERTIFICATE-----\n", 4096) = 2049 <0.000026>
23867 1561368758.455309 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fc157ffc8e0, 2049, 0x7fc1c10db588, 0x7fc157ffc8c8 <unfinished ...>

 

Looking at the "good" trace, there seems to be a pattern of a 7, 128 and a 256 maxlength which repeats for a while...

 

24146 1561369233.774199 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff91e1, 7, 0x7f1172fcb1e0,
0x7f111dff90d0 <unfinished ...>
24146 1561369233.776327 <... curl_mvsnprintf resumed> ) = 3 <0.002121>
24146 1561369233.796293 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9180, 128, 0x7f1172fcbb0a, 0x7f111dff90a0 <unfinished ...>
24146 1561369233.797648 <... curl_mvsnprintf resumed> ) = 26 <0.001349>
24146 1561369234.085892 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9260, 256, 0x7f1172fc6be8, 0x7f111dff9170 <unfinished ...>
24146 1561369234.087576 <... curl_mvsnprintf resumed> ) = 57 <0.001677>
24146 1561369234.145964 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff91e1, 7, 0x7f1172fcb1e0,
0x7f111dff90d0 <unfinished ...>
24146 1561369234.147276 <... curl_mvsnprintf resumed> ) = 3 <0.001305>
24146 1561369234.161595 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9180, 128, 0x7f1172fcbb0a, 0x7f111dff90a0 <unfinished ...>
24146 1561369234.162919 <... curl_mvsnprintf resumed> ) = 26 <0.001318>
24146 1561369234.464201 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9260, 256, 0x7f1172fc6be8, 0x7f111dff9170 <unfinished ...>
24146 1561369234.465540 <... curl_mvsnprintf resumed> ) = 57 <0.001332>
24146 1561369235.416065 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff91e1, 7, 0x7f1172fcb1e0,
0x7f111dff90d0 <unfinished ...>
24146 1561369235.417466 <... curl_mvsnprintf resumed> ) = 3 <0.001388>
24146 1561369235.437715 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9180, 128, 0x7f1172fcbb0a, 0x7f111dff90a0 <unfinished ...>
24146 1561369235.446180 <... curl_mvsnprintf resumed> ) = 26 <0.008463>
24146 1561369235.847103 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9260, 256, 0x7f1172fc6be8, 0x7f111dff9170 <unfinished ...>
24146 1561369235.849220 <... curl_mvsnprintf resumed> ) = 57 <0.002108>
24146 1561369238.366226 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff91e1, 7, 0x7f1172fcb1e0,
0x7f111dff90d0 <unfinished ...>
24146 1561369238.367640 <... curl_mvsnprintf resumed> ) = 3 <0.001404>
24146 1561369238.385993 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9180, 128, 0x7f1172fcbb0a, 0x7f111dff90a0 <unfinished ...>
24146 1561369238.388487 <... curl_mvsnprintf resumed> ) = 26 <0.002487>
24146 1561369238.748475 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f111dff9260, 256, 0x7f1172fc6be8, 0x7f111dff9170 <unfinished ...>
24146 1561369238.750093 <... curl_mvsnprintf resumed> ) = 57 <0.001612>

 

but on a segfault one, this jumps from 128 to 2049....

 

 

23867 1561368758.042046 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fc157ffd1e1, 7, 0x7fc1c10da1e0,
0x7fc157ffd0d0 <unfinished ...>
23867 1561368758.043383 <... curl_mvsnprintf resumed> )    = 3 <0.001331>
23867 1561368758.062192 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fc157ffd180, 128, 0x7fc1c10dab0a, 0x7fc157ffd0a0 <unfinished ...>
23867 1561368758.065569 <... curl_mvsnprintf resumed> )    = 26 <0.003370>
23867 1561368758.364087 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fc157ffd260, 256, 0x7fc1c10d5be8, 0x7fc157ffd170 <unfinished ...>
23867 1561368758.365942 <... curl_mvsnprintf resumed> )    = 57 <0.001848>
23867 1561368758.435456 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fc157ffd1e1, 7, 0x7fc1c10da1e0,
0x7fc157ffd0d0 <unfinished ...>
23867 1561368758.438399 <... curl_mvsnprintf resumed> )    = 3 <0.002934>
23867 1561368758.452583 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fc157ffd180, 128, 0x7fc1c10dab0a, 0x7fc157ffd0a0 <unfinished ...>
23867 1561368758.454919 <... curl_mvsnprintf resumed> )    = 26 <0.002331>
23867 1561368758.455309 libcurl-gnutls.so.4->curl_mvsnprintf(0x7fc157ffc8e0, 2049, 0x7fc1c10db588, 0x7fc157ffc8c8 <unfinished ...>

 

 

 

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

Interestingly, if I get a core dump from it when it segfaults and run spotify through gdb with the core I can see what was at the address of the output buffer for curl_mvsnprintf... i.e. 

 

29666 1561378833.635000 libcurl-gnutls.so.4->curl_mvsnprintf(0x7f07eaffa8e0, 2049, 0x7f083f6e7588, 0x7f07eaffa8c8)
                                    = 53 <0.002275>

which shows...

 

(gdb) x/1s 0x7f07eaffa8e0
0x7f07eaffa8e0: "17 bytes stray data read before trying h2 connection\n"

which can be seen in the curl source here...

 

https://github.com/curl/curl/blob/master/lib/http2.c

 

in the http2_connisdead function...

 

 

 

/*
 * The server may send us data at any point (e.g. PING frames). Therefore,
 * we cannot assume that an HTTP/2 socket is dead just because it is readable.
 *
 * Instead, if it is readable, run Curl_connalive() to peek at the socket
 * and distinguish between closed and data.
 */
static bool http2_connisdead(struct connectdata *conn)
{
  int sval;
  bool dead = TRUE;

  if(conn->bits.close)
    return TRUE;

  sval = SOCKET_READABLE(conn->sock[FIRSTSOCKET], 0);
  if(sval == 0) {
    /* timeout */
    dead = FALSE;
  }
  else if(sval & CURL_CSELECT_ERR) {
    /* socket is in an error state */
    dead = TRUE;
  }
  else if(sval & CURL_CSELECT_IN) {
    /* readable with no error. could still be closed */
    dead = !Curl_connalive(conn);
    if(!dead) {
      /* This happens before we've sent off a request and the connection is
         not in use by any other transfer, there shouldn't be any data here,
         only "protocol frames" */
      CURLcode result;
      struct http_conn *httpc = &conn->proto.httpc;
      ssize_t nread = -1;
      if(httpc->recv_underlying)
        /* if called "too early", this pointer isn't setup yet! */
        nread = ((Curl_recv *)httpc->recv_underlying)(
          conn, FIRSTSOCKET, httpc->inbuf, H2_BUFSIZE, &result);
      if(nread != -1) {
        infof(conn->data,
              "%d bytes stray data read before trying h2 connection\n",
              (int)nread);
        httpc->nread_inbuf = 0;
        httpc->inbuflen = nread;
        (void)h2_process_pending_input(conn, httpc, &result);
      }
      else
        /* the read failed so let's say this is dead anyway */
        dead = TRUE;
    }
  }

  return dead;
}

 

 

Re: Segmentation fault (core dumped) is back

thereal_rjf
Music Fan

I compiled gnutls and curl (compiled against gnutls) from latest source and ran my version of spotify. All fixed. Looks like the problem in curl handling of multi events... which rather embarasingly is the problem pointed out by the chap in the other thread (Ubuntu problems / segfaults) about the lib curl problems :) Sorry chaps for wasting more of your time. Apollogies for blaming the spotify app here. Cheers.

Re: Segmentation fault (core dumped) is back

hypergig
Regular

this seems to be a work around

 

$ until spotify; do echo try again; done
[0100/000000.820699:FATAL:memory.cc(22)] Out of memory. size=4194304
Segmentation fault (core dumped)
try again
Segmentation fault (core dumped)
try again
Segmentation fault (core dumped)
try again
[0100/000000.589403:FATAL:memory.cc(22)] Out of memory. size=4194304
Segmentation fault (core dumped)
try again
Segmentation fault (core dumped)
try again

Please turn your head away from your computer before throwing up, I am not responsible for broken keyboards and/or laptops

Re: Segmentation fault (core dumped) is back

grimpressive
Casual Listener

20 minutes to get it running.

 

Woah.

Re: Segmentation fault (core dumped) is back

tomaspinho
Casual Listener

Snap version runs well (compatible libraries are probably inside the snap)

Re: Segmentation fault (core dumped) is back

grimpressive
Casual Listener

Totally disagree.

 

Snap version has no media keys working AND suffers from segfault just like the .deb one.

 

...at least, on my machine running an up-to-date 19.04 Ubuntu.

Re: Segmentation fault (core dumped) is back

tomaspinho
Casual Listener

Also running up-to-date Ubuntu 19.04. The snap version hasn't crashed once. But it does take longer to spawn.

SUGGESTED POSTS