segfault in _int_malloc after QMetaObject::activate
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Invalid
|
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@
at malloc.c:3779
#1 0x00007f5f7e8962ed in __GI___libc_malloc (bytes=24) at malloc.c:3065
#2 0x00007f5f8333f011 in QMetaObject:
at /usr/lib/
#3 0x000055ce2d7d19dc in ControlDoublePr
#4 0x000055ce2d7be0d5 in ControlDoublePr
#5 0x000055ce2d7be18f in ControlDoublePr
#6 0x000055ce2da6e315 in ControlObject:
at src/control/
#7 0x000055ce2da6e315 in EngineVuMeter:
#8 0x000055ce2da67c4b in EngineMaster:
#9 0x000055ce2ddb79fb in SoundManager:
#10 0x000055ce2ddb0ef4 in SoundDevicePort
at src/soundio/
#11 0x00007f5f864508b4 in () at /usr/lib/
#12 0x00007f5f864528c4 in () at /usr/lib/
#13 0x00007f5f8645b7cc in () at /usr/lib/
#14 0x00007f5f80e596db in start_thread (arg=0x7f5e55ff
#15 0x00007f5f7e92088f in clone () at ../sysdeps/
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 d9d7ea6404de71c
Merge: 0e685c1a9 7f1d14931
Author: Daniel Schürmann <email address hidden>
Date: Mon Dec 24 07:37:23 2018 +0100
Changed in mixxx: | |
importance: | Undecided → Critical |
milestone: | none → 2.2.1 |
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?