# Mumble segfaults on libQtCore on connect

## pa4wdh

Hi All,

I'm using mumble to connect to a murmur server to have voice calls. It all worked quite well, but suddenly it stopped working  :Sad: 

Whenever i connect to a murmur server mumble segfaults, this is the line in dmesg with the segfault:

```

mumble[4465]: segfault at 70 ip b64981eb sp bfea2020 error 4 in libQtCore.so.4.6.2[b63a0000+283000]

```

When run on the CLI this is the output i get:

```

~ $ mumble

CELT bitstream 8000000b from libcelt0.so.0.0.0

Locale is C

TextToSpeech: Compiled without support for speech-dispatcher

OpenSSL Support: 1

SSL: Added CA certificates from '/etc/ssl/certs/ca-certificates.crt'

Overlay: Removing old socket on "/home/pa4wdh/.MumbleOverlayPipe" 

Overlay: Listening on "/home/pa4wdh/.MumbleOverlayPipe" 

GlobalShortcutX: Unable to open any keyboard input devices under /dev/input, falling back to XInput

GlobalShortcutX: Using XInput 2.0

GlobalShortcutX: XInput 4:Virtual core XTEST pointer

GlobalShortcutX: XInput 5:Virtual core XTEST keyboard

GlobalShortcutX: XInput 6:Mouse0

GlobalShortcutX: XInput 7:mouse1

GlobalShortcutX: XInput 8:Keyboard0

SocketRPC: Removing old socket on "/home/pa4wdh/.MumbleSocket" 

AudioInput: 40000 bits/s, 48000 hz, 480 sample CELT

ALSAAudioOutput: Initialized

ALSA lib pcm_hw.c:1433:(_snd_pcm_hw_open) Invalid value for card

ALSAAudio: snd_pcm_open(&pcm_handle, device_name.data(), SND_PCM_STREAM_PLAYBACK, 0): No such device

ALSAAudioOutput: Actual buffer 48000 hz, 1 channel 2880 samples [480 per period]

ALSAAudioInput: Initing audiocapture hw:CARD=default,DEV=0.

ALSA lib pcm_hw.c:1433:(_snd_pcm_hw_open) Invalid value for card

ALSAAudio: snd_pcm_open(&capture_handle, device_name.data(), SND_PCM_STREAM_CAPTURE, 0): No such device

ALSAAudioInput: Actual buffer 48000 hz, 1 channel 3840 samples [480 per period]

OSInfo: Failed to execute lsb_release

Segmentation fault

```

Don't mind the ALSA messages about the card, that's because my USB headset isn't connected at the moment, but the same happens if it is.

Last changes on the system where a kernel upgrade from 2.6.31.6 to 2.6.34 and an emerge -e world after changing gcc 4.4.3. I ran emerge -e world after changing back to gcc 4.3.4 and booted the old kernel, but that doesn't help.

Any suggestions ?

Best regards,

pa4wdh

----------

## Hu

Please collect a backtrace of the crash.  You may need to rebuild some components according to the instructions in How to get meaningful backtraces in Gentoo, since most users normally build without the debugging information required for this exercise.  Since no core file is generated, you will probably need to start mumble under control of sys-devel/gdb so that the debugger breaks in as soon as the fault occurs.

----------

## pa4wdh

Thanks for your suggestion.

I think i'll edit make.conf and run emerge -e mumble, which will rebuild mumble and everything it depends on with the settings. Or is there a better way ? I guess if i only rebuild qt-core and mumble i might still miss information ?

----------

## Hu

I would start with rebuilding media-sound/mumble and x11-libs/qt-core.  You may need to rebuild more packages to get a good trace, but there is no harm in trying it with a subset first.  Rebuilding everything is probably excessive.

----------

## pa4wdh

I'm sorry it took a while before i was able to do this. Besides mumble and qt-core i also had to rebuild libsndfile and now have what my untrained eyes see as a valid backtrace:

```

#0  0xb6c5f4cb in QFile::size (this=0x86bfaf4) at io/qfile.cpp:1419

#1  0x080e04c6 in SoundFile::vio_get_filelen (user_data=0x86bfad0)

    at AudioOutput.cpp:176

#2  0xb7d13351 in psf_get_filelen (psf=0x86c9c90) at file_io.c:175

#3  0xb7ceb94d in psf_open_file (psf=0x86c9c90, sfinfo=0x86bfadc)

    at sndfile.c:2591

#4  0xb7cecbce in sf_open_virtual (sfvirtual=0x83b4078, mode=16, 

    sfinfo=0x86bfadc, user_data=0x86bfad0) at sndfile.c:391

#5  0x080e0b27 in SoundFile (this=0x86bfad0, fname=...) at AudioOutput.cpp:133

#6  0x080e4996 in AudioOutputSample::loadSndfile (filename=...)

    at AudioOutput.cpp:271

#7  0x080e5474 in AudioOutput::playSample (this=0x85bc6d8, filename=..., 

    loop=false) at AudioOutput.cpp:780

#8  0x080c0078 in Log::log (this=0x8497be0, mt=Log::ServerConnected, 

    console=..., terse=...) at Log.cpp:557

#9  0x080efa63 in MainWindow::serverConnected (this=0x858b038)

    at MainWindow.cpp:1972

#10 0x081eddfc in MainWindow::qt_metacall (this=0x858b038, 

    _c=QMetaObject::InvokeMetaMethod, _id=71, _a=0xb3b0df40)

    at moc_MainWindow.cpp:302

#11 0xb6cdb605 in QMetaObject::metacall (object=0x1, 

    cl=QMetaObject::InvokeMetaMethod, idx=102, argv=0xb3b0df40)

    at kernel/qmetaobject.cpp:237

#12 0xb6ce5aa6 in QMetaCallEvent::placeMetaCall (this=0xb3b18af0, 

    object=0x858b038) at kernel/qobject.cpp:561

#13 0xb6ce6ff3 in QObject::event (this=0x858b038, e=0xb3b18af0)

    at kernel/qobject.cpp:1240

#14 0xb70aac5a in QWidget::event(QEvent*) () from /usr/lib/qt4/libQtGui.so.4

#15 0xb74d56dc in QMainWindow::event(QEvent*) ()

   from /usr/lib/qt4/libQtGui.so.4

#16 0xb704a74c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()

   from /usr/lib/qt4/libQtGui.so.4

#17 0xb70520d5 in QApplication::notify(QObject*, QEvent*) ()

   from /usr/lib/qt4/libQtGui.so.4

#18 0xb6cd62bb in QCoreApplication::notifyInternal (this=0xbfffeeb0, 

    receiver=0x858b038, event=0xb3b18af0) at kernel/qcoreapplication.cpp:704

#19 0xb6cd71df in QCoreApplication::sendEvent (receiver=0x0, event_type=0, 

    data=0x83b6390) at kernel/qcoreapplication.h:215

#20 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, 

    data=0x83b6390) at kernel/qcoreapplication.cpp:1345

#21 0xb6cd738d in QCoreApplication::sendPostedEvents (receiver=0x0, 

    event_type=0) at kernel/qcoreapplication.cpp:1238

#22 0xb6d0235f in QCoreApplication::sendPostedEvents (s=0x83bdf40)

    at kernel/qcoreapplication.h:220

#23 postEventSourceDispatch (s=0x83bdf40)

    at kernel/qeventdispatcher_glib.cpp:276

#24 0xb6518f7e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0

```

As far as i can see it seems it wants to read the size of a file, but failing to do that shouldn't lead to a segfault in my opinion.

I tried to run mumble with an strace or "bt full" in gdb, but that doesn't reveal the file it's searching for.

Any clues ?

----------

## pa4wdh

I just noticed mumble is multi-threaded, here's the backtrace made with "thread apply all bt":

```

Thread 9 (Thread 0xb2887b70 (LWP 21027)):

#0  0xb7fe0424 in __kernel_vsyscall ()

#1  0xb69509d1 in select () from /lib/libc.so.6

#2  0xb6cb2681 in QProcessManager::run (this=0xb6dec890)

    at io/qprocess_unix.cpp:245

#3  0xb6bd2aae in QThreadPrivate::start (arg=0xb6dec890)

    at thread/qthread_unix.cpp:248

#4  0xb6b5067f in start_thread () from /lib/libpthread.so.0

#5  0xb695795e in clone () from /lib/libc.so.6

Thread 8 (Thread 0xb3088b70 (LWP 21026)):

#0  0xb7fe0424 in __kernel_vsyscall ()

#1  0xb694d3d7 in poll () from /lib/libc.so.6

#2  0xb652a16b in g_poll () from /usr/lib/libglib-2.0.so.0

#3  0x00000003 in ?? ()

Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 7 (Thread 0xb44e2b70 (LWP 21025)):

#0  0xb7fe0424 in __kernel_vsyscall ()

#1  0xb6b546e2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()

   from /lib/libpthread.so.0

#2  0xb6bd398c in QWaitConditionPrivate::wait (this=0x8601d84, 

    mutex=0x8601d80, time=30000) at thread/qwaitcondition_unix.cpp:85

#3  QWaitCondition::wait (this=0x8601d84, mutex=0x8601d80, time=30000)

    at thread/qwaitcondition_unix.cpp:159

#4  0xb6bc86bb in QThreadPoolThread::run (this=0xb3a02f80)

    at concurrent/qthreadpool.cpp:140

#5  0xb6bd2aae in QThreadPrivate::start (arg=0xb3a02f80)

    at thread/qthread_unix.cpp:248

#6  0xb6b5067f in start_thread () from /lib/libpthread.so.0

#7  0xb695795e in clone () from /lib/libc.so.6

Thread 6 (Thread 0xb39bbb70 (LWP 21023)):

#0  0xb7fe0424 in __kernel_vsyscall ()

#1  0xb6b546e2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()

   from /lib/libpthread.so.0

#2  0xb6bd398c in QWaitConditionPrivate::wait (this=0x8601d84, 

    mutex=0x8601d80, time=30000) at thread/qwaitcondition_unix.cpp:85

#3  QWaitCondition::wait (this=0x8601d84, mutex=0x8601d80, time=30000)

    at thread/qwaitcondition_unix.cpp:159

#4  0xb6bc86bb in QThreadPoolThread::run (this=0x8601f60)

    at concurrent/qthreadpool.cpp:140

#5  0xb6bd2aae in QThreadPrivate::start (arg=0x8601f60)

    at thread/qthread_unix.cpp:248

#6  0xb6b5067f in start_thread () from /lib/libpthread.so.0

#7  0xb695795e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb6397710 (LWP 21016)):

#0  0xb6c5f4cb in QFile::size (this=0x869db64) at io/qfile.cpp:1419

#1  0x080e04c6 in SoundFile::vio_get_filelen (user_data=0x869db40)

    at AudioOutput.cpp:176

#2  0xb7d13351 in psf_get_filelen (psf=0x8772008) at file_io.c:175

#3  0xb7ceb94d in psf_open_file (psf=0x8772008, sfinfo=0x869db4c)

    at sndfile.c:2591

#4  0xb7cecbce in sf_open_virtual (sfvirtual=0x83b4078, mode=16, 

    sfinfo=0x869db4c, user_data=0x869db40) at sndfile.c:391

#5  0x080e0b27 in SoundFile (this=0x869db40, fname=...) at AudioOutput.cpp:133

#6  0x080e4996 in AudioOutputSample::loadSndfile (filename=...)

    at AudioOutput.cpp:271

#7  0x080e5474 in AudioOutput::playSample (this=0x85bf718, filename=..., 

    loop=false) at AudioOutput.cpp:780

#8  0x080c0078 in Log::log (this=0x8497be0, mt=Log::ServerConnected, 

    console=..., terse=...) at Log.cpp:557

#9  0x080efa63 in MainWindow::serverConnected (this=0x858b038)

    at MainWindow.cpp:1972

#10 0x081eddfc in MainWindow::qt_metacall (this=0x858b038, 

    _c=QMetaObject::InvokeMetaMethod, _id=71, _a=0x869aa88)

    at moc_MainWindow.cpp:302

#11 0xb6cdb605 in QMetaObject::metacall (object=0x1, 

    cl=QMetaObject::InvokeMetaMethod, idx=102, argv=0x869aa88)

    at kernel/qmetaobject.cpp:237

#12 0xb6ce5aa6 in QMetaCallEvent::placeMetaCall (this=0x86c4500, 

    object=0x858b038) at kernel/qobject.cpp:561

#13 0xb6ce6ff3 in QObject::event (this=0x858b038, e=0x86c4500)

    at kernel/qobject.cpp:1240

#14 0xb70aac5a in QWidget::event(QEvent*) () from /usr/lib/qt4/libQtGui.so.4

#15 0xb74d56dc in QMainWindow::event(QEvent*) ()

   from /usr/lib/qt4/libQtGui.so.4

#16 0xb704a74c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()

   from /usr/lib/qt4/libQtGui.so.4

#17 0xb70520d5 in QApplication::notify(QObject*, QEvent*) ()

   from /usr/lib/qt4/libQtGui.so.4

#18 0xb6cd62bb in QCoreApplication::notifyInternal (this=0xbfffeeb0, 

    receiver=0x858b038, event=0x86c4500) at kernel/qcoreapplication.cpp:704

#19 0xb6cd71df in QCoreApplication::sendEvent (receiver=0x0, event_type=0, 

    data=0x83b6390) at kernel/qcoreapplication.h:215

#20 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, 

    data=0x83b6390) at kernel/qcoreapplication.cpp:1345

#21 0xb6cd738d in QCoreApplication::sendPostedEvents (receiver=0x0, 

    event_type=0) at kernel/qcoreapplication.cpp:1238

#22 0xb6d0235f in QCoreApplication::sendPostedEvents (s=0x83bdf40)

    at kernel/qcoreapplication.h:220

#23 postEventSourceDispatch (s=0x83bdf40)

    at kernel/qeventdispatcher_glib.cpp:276

#24 0xb6518f7e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0

```

----------

## Hu

 *pa4wdh wrote:*   

> As far as i can see it seems it wants to read the size of a file, but failing to do that shouldn't lead to a segfault in my opinion.

 Agreed.  However, it is possible that QFile::size might be written in such a way that it can be crashed with bad inputs.  In =x11-libs/qt-core-4.6.2-r1, QFile::size is:

```
  1175   qint64 QFile::size() const

  1176   {

  1177       Q_D(const QFile);

  1178       if (!d->ensureFlushed())

  1179           return 0;

  1180       return fileEngine()->size();

  1181   }
```

If fileEngine() returned NULL, then the program might crash.  Could you open the backtrace again, select that thread, and print *this?

----------

## pa4wdh

Thanks for your help so far Hu. If a badly written program could make that pointer invalid, it might even be a security hole in my opinion.

However, i'm not a gdb guru, so i ran mumble up to where it segfaults, the backtrace showed thread 1 was the one using QFile::size, so i used the command thread aply 1 print *this and got the following output:

```

Thread 1 (Thread 0xb6397710 (LWP 4519)):

$1 = {<QIODevice> = {<QObject> = {_vptr.QObject = 0x0, 

      static staticMetaObject = {d = {superdata = 0x0, 

          stringdata = 0xb6d82f00 "QObject", data = 0xb6d82fa0, 

          extradata = 0xb6de62c0}}, d_ptr = {d = 0x86201f8}, 

      static staticQtMetaObject = {d = {superdata = 0x0, 

          stringdata = 0xb6d8ba40 "Qt", data = 0xb6d8f060, extradata = 0x0}}}, 

    static staticMetaObject = {d = {superdata = 0x83b4440, 

        stringdata = 0xb6d93a80 "QIODevice", data = 0xb6d93ae0, 

        extradata = 0x0}}}, static staticMetaObject = {d = {

      superdata = 0xb6deac48, stringdata = 0xb6d93a00 "QFile", 

      data = 0xb6d93a20, extradata = 0x0}}}

```

I can't see any useful data in there, but i hope the presence of the stringdata "QFile" means i selected the right thread  :Smile: 

Is this what you're looking for ?

----------

## Hu

 *pa4wdh wrote:*   

> I can't see any useful data in there, but i hope the presence of the stringdata "QFile" means i selected the right thread 
> 
> Is this what you're looking for ?

 You did what I asked, but the output was not as helpful as I had hoped (through no fault of yours).  I will need to dig into the Qt code to understand how to apply the information you have provided.

After looking at it, I am a bit puzzled.  The output you showed looks well formed, but does not have any of the members I would expect based on inspecting the corresponding code.  You may need to enlist the aid of someone familiar with QFile to proceed further.  I suspect you will end up debugging mumble live, rather than inspecting a core dump.

You could also try using dev-util/strace to see if there are any failed file accesses shortly before the crash.  However, modern systems have a significant number of non-fatal failed file accesses when searching for libraries, so that can be noisy.

----------

## pa4wdh

Thanks again Hu.

I couldn't find any clues in an strace. If you want to take a look at it you can find it here: http://www.xs4all.nl/~ernstagn/gentoo/logs/strace_mumble.log

Debugging mumble or qt wasn't really what i hoped for when i started this thread  :Smile: 

One strange thing is that i have an other PC which has the same portage tree (they both sync from a private mirror) and there it works. There are three major differences:

- The working one has the dbus use flag set on mumble, the not working doesn't. However, i tried that at the non working one and that didn't change the situation

- The working one has prescott architecture in cflags the not working one has core2

- The working one is a single core, the not working one a dual core

----------

## Hu

As a quick check to see if threading is a problem, you can use taskset to bind a process so that all of its threads will run on a single core.  This should reduce the chance of hitting race conditions, which may avoid the crash if the problem is related to inadequate synchronization.

----------

## pa4wdh

I tried taskset 0x00000001 mumble, but still the same result.  :Sad: 

----------

## pa4wdh

*bump*

Is there anyone with neat ideas to investigate or solve this problem ?

----------

## netfab

Bump. I have exactly the same crash each time mumble wants to play a (embedded) notification sound.

Mumble 1.2.3_rc1, qt-*-4.6.3 packages, mostly stable x86 system. I tried to rebuild qt-*, libsndfile, mumble, alsa-lib, always the same result.

I can reproduce the crash on two different x86 systems, built with CFLAGS="-O2 -march=i686 -pipe -mmmx -msse".

Output of valgrind :

 *Quote:*   

> 
> 
> ==3847== Thread 1:
> 
> ==3847== Invalid read of size 4
> ...

 

The code around line 1426 of qfile.cpp in QT 4.6.3 :

```

1421    qint64 QFile::size() const

1422    {

1423        Q_D(const QFile);

1424        if (!d->ensureFlushed())

1425            return 0;

1426        d->cachedSize = fileEngine()->size();

1427        return d->cachedSize;

1428    }

```

Any idea ?

----------

## Hu

That is consistent with fileEngine() returning NULL.  That callstack looks like it is crossing back and forth between libsndfile and Qt.  I think you need to determine why that instance of QFile gets NULL when it calls fileEngine().

----------

## netfab

I tried to rebuild qt-core with the following patch :

```

--- src/corelib/io/qfile.cpp.old   2011-01-17 12:46:48.977178002 +0100

+++ src/corelib/io/qfile.cpp   2011-01-17 12:49:20.282178002 +0100

@@ -1423,6 +1423,10 @@

     Q_D(const QFile);

     if (!d->ensureFlushed())

         return 0;

+    if ( ! fileEngine() ) {

+        qWarning("fileEngine is NULL, avoiding crash !");

+        return 0;

+    }

     d->cachedSize = fileEngine()->size();

     return d->cachedSize;

 }

```

It crash exactly in the same way, at line 1426. So the crash occurs when calling the fileEngine() member function.

Unfortunately I don't have the time to debug this, I tried to search for existing bugs (click), I found nothing about this particular crash, but I found something that does not encourage me to go further : please look at this bugreport closed as invalid with this answer :

 *Quote:*   

> 
> 
> The only sensible thing that Qt can do is to return 0 and hope that everything is going ok underneath.
> 
> 

 

I do not pretend to know everything about programmation, I'm not a professional programmer, and this is the first time that I have to deal with Qt, but I sincerely hope that the entire library is not built with the hope that everything is going ok underneath, otherwise I'm not surprised that it crash without explanations...

----------

