segfault in _int_malloc after QMetaObject::activate

Bug #1810381 reported by Stephane Bernaud on 2019-01-03
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Critical
Unassigned

Bug Description

I was using my controller (kontrol S4 mk2) with sound playing and two tracks loaded and i faced a sudden segfault, but couldn't find find any interesting info. After allowing core file creation, mixxx segfaulted again (randomly, sound was playing) and i was able to extract a backtrace :

#0 0x00007f5f7e8935bd in _int_malloc (av=av@entry=0x7f5e5c000020, bytes=bytes@entry=24)
    at malloc.c:3779
#1 0x00007f5f7e8962ed in __GI___libc_malloc (bytes=24) at malloc.c:3065
#2 0x00007f5f8333f011 in QMetaObject::activate(QObject*, int, int, void**) ()
    at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3 0x000055ce2d7d19dc in ControlDoublePrivate::valueChanged(double, QObject*) (this=this@entry=0x55ce30a11dc0, _t1=<optimized out>, _t1@entry=1, _t2=<optimized out>) at lin64_build/control/moc_control.cc:140
#4 0x000055ce2d7be0d5 in ControlDoublePrivate::setInner(double, QObject*) (this=0x55ce30a11dc0, value=1, pSender=<optimized out>) at src/control/control.cpp:201
#5 0x000055ce2d7be18f in ControlDoublePrivate::set(double, QObject*) (this=0x55ce30a11dc0, value=<optimized out>, pSender=0x55ce30a11cd0) at src/control/control.cpp:188
#6 0x000055ce2da6e315 in ControlObject::set(double) (value=<optimized out>, this=<optimized out>)
    at src/control/controlobject.h:96
#7 0x000055ce2da6e315 in EngineVuMeter::process(float*, int) (this=0x55ce30a66e20, pIn=<optimized out>, iBufferSize=2048) at src/engine/enginevumeter.cpp:86
#8 0x000055ce2da67c4b in EngineMaster::process(int) (this=0x55ce30a09680, iBufferSize=iBufferSize@entry=2048) at src/engine/enginemaster.cpp:706
#9 0x000055ce2ddb79fb in SoundManager::onDeviceOutputCallback(long) (this=<optimized out>, iFramesPerBuffer=iFramesPerBuffer@entry=1024) at src/soundio/soundmanager.cpp:599
#10 0x000055ce2ddb0ef4 in SoundDevicePortAudio::callbackProcessClkRef(long, float*, float const*, PaStreamCallbackTimeInfo const*, unsigned long) (this=0x55ce3125e920, framesPerBuffer=<optimized out>, out=<optimized out>, in=<optimized out>, timeInfo=<optimized out>, statusFlags=<optimized out>)
    at src/soundio/sounddeviceportaudio.cpp:942
#11 0x00007f5f864508b4 in () at /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#12 0x00007f5f864528c4 in () at /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#13 0x00007f5f8645b7cc in () at /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#14 0x00007f5f80e596db in start_thread (arg=0x7f5e55ffb700) at pthread_create.c:463
#15 0x00007f5f7e92088f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Operating system :
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

CPU architecture : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
$ uname -a
Linux oleg 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Your video
$ sudo lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)

sound hardware
traktor kontrol S4 mk2 one

mixxx version : 2.2
$ git log --max-count=1
commit d9d7ea6404de71c86beacfc86f9087dc8db0fc58 (HEAD -> 2.2, tag: release-2.2.0, origin/2.2)
Merge: 0e685c1a9 7f1d14931
Author: Daniel Schürmann <email address hidden>
Date: Mon Dec 24 07:37:23 2018 +0100

Be (be.ing) on 2019-01-03
Changed in mixxx:
importance: Undecided → Critical
milestone: none → 2.2.1
Daniel Schürmann (daschuer) wrote :

If malloc.c segfaults, it tries to allocate memory on a bad address. This can happen if either the Ram is faulty or a previous call previus call has corrupted the heap control structure.
I assume the error is unrelated to the current call in the stack trace.

Can you find a pattern that always crashes?
Did you do something special before the crash?

Stephane Bernaud (uraoul) wrote :

just did a memtest86 which is 100% OK.

No, I haven't find a pattern that always crash (which are pretty rare).

RJ Skerry-Ryan (rryan) wrote :

Could you please paste the result of "thread apply all bt" instead of just the backtrace for the single thread? That will let us see what the controller thread was doing at the time the crash happened.

Stephane Bernaud (uraoul) wrote :

Sorry but i don't have the binary anymore and thus cannot generate backtrace for threads.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers