slow down and SIGKILL at startup

[Stéphane Guillou]

I was having an issue on my KXstudio 14.04 64 bits install with the 1.12 beta a while ago, which I reported on the forum (http://mixxx.org/forums/viewtopic.php?f=1&t=7131&start=90#p25124), and I thought I'd report it here in case it is an actual bug that might affect other users, although now it seems like a somewhat different issue.

What happens now:
I try to launch Mixxx, the splash screen appears, the progress bar starts filling up and then the system is super slow or frozen until Mixxx crashes. The last lines in the gdb output are:
"Program terminated with signal SIGKILL, Killed.
The program no longer exists."

Mixxx version (latest from testing PPA at the time of writing):
2.0-rc1-git5641-ppa1~trusty1

Here are my configuration details (output of 'inxi -Fx'):

System: Host: chtfn-X201EP-KX14 Kernel: 3.13.0-68-lowlatency x86_64 (64 bit, gcc: 4.8.2)
           Desktop: KDE 4.13.3 (Qt 4.8.6) Distro: Ubuntu 14.04 trusty
Machine: System: ASUSTeK (portable) product: X201EP version: 1.0
           Mobo: ASUSTeK model: X201EP version: 1.0 Bios: American Megatrends version: X201EP.208 date: 01/18/2013
CPU: Dual core Intel Celeron CPU 847 (-MCP-) cache: 2048 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 4390.12
           Clock Speeds: 1: 1100.00 MHz 2: 800.00 MHz
Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller bus-ID: 00:02.0
           X.Org: 1.15.1 drivers: intel (unloaded: fbdev,vesa) Resolution: 1366x768@60.0hz
           GLX Renderer: Mesa DRI Intel Sandybridge Mobile GLX Version: 3.0 Mesa 10.1.3 Direct Rendering: Yes
Audio: Card: Intel 7 Series/C210 Series Family High Definition Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: Advanced Linux Sound Architecture ver: k3.13.0-68-lowlatency
Network: Card-1: Qualcomm Atheros AR9485 Wireless Network Adapter driver: ath9k bus-ID: 02:00.0
           IF: wlan0 state: up mac: 6c:71:d9:35:0e:7a
           Card-2: Qualcomm Atheros AR8162 Fast Ethernet driver: alx port: e000 bus-ID: 03:00.0
           IF: eth0 state: down mac: 60:a4:4c:d9:07:c1
Drives: HDD Total Size: 500.1GB (78.3% used) 1: id: /dev/sda model: ST500LT012 size: 500.1GB
Partition: ID: / size: 405G used: 365G (96%) fs: ext4 ID: swap-1 size: 4.17GB used: 0.76GB (18%) fs: swap
RAID: No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors: System Temperatures: cpu: 66.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info: Processes: 187 Uptime: 3:51 Memory: 943.5/3836.8MB Runlevel: 2 Gcc sys: 4.9.3
           Client: Shell (bash 4.3.11) inxi: 1.9.17

And attached are both the log and the gdb output. 'thread apply all bt' did not have any effect.

[Daniel Schürmann (daschuer)]

It looks like Mixxx is killed by Linux, because it reaches a limit somehow.

Please whatch the memory consumption using gnome-system-monitor or similar, maybe there is a big memory leak.

[Stéphane Guillou (stephane-guillou)]

Hi Daniel
Thanks for the reply.

Yes, I used the KDE system monitor and when the system froze for a minute while starting Mixxx, Mixxx was using more than 1.25 Gigs of memory. Even after the process is killed, the system is very sluggish, with processes going to disk sleep (like Firefox, Evolution and KDE Plasma).

[Stéphane Guillou (stephane-guillou)]

How can I further troubleshoot?

[Daniel Schürmann (daschuer)]

My Mixxx uses 158 MB with Deree skin on Ubuntu Trusty.

To identify the memory leaks, you can use valgrind.
But be warned, valgrind makes Mixxx veeery slow.

We have a known memory leak when running with --developer option.
Do you set this flag?

Since no other user experience it, it might be a graphic card issue.
Do you use a recent driver?

Other test ideas:
* Start with Shade skin, which is less memory consuming.
* disable spines and waveforms.

[Stéphane Guillou (stephane-guillou)]

I am not using the --developer option.

I used valgrind --tool=memcheck, and the output is attached.
I did notice that the freeze/extreme slow down happened when the following line appeared:

Debug [Main]: LegacySkinParser loading skin: "/usr/share/mixxx/skins/Deere"

How can I start with the Shade skin? I could not find a command line option to set that. I can not change it from the GUI as I can't start it at all.
Same thing with spinnies and waveform.

And I should say, this is happening on my KXStudio 14.04 install that I have been using for a while, whereas I dual boot with a fresh KXStudio 14.04.1 install where the problem does not occur. However, I thought I'd still report it as it might reveal something interesting, some interaction with the packages I have at the moment, or something that has to do with transitioning from Mixxx 1.11 to 2.0, given that Mixxx 1.11 used to work perfectly fine on this install.

Cheers

[Daniel Schürmann (daschuer)]

Open ~/.mixxx/mixxx.cfg and replace Deere with Shade

[Config]
ResizableSkin Shade

[Daniel Schürmann (daschuer)]

This one is scary:

ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connexion refusée
...
Processus arrêté

What might be the origin of "Processus arrêté"
This seams to be a translated string, but it seams to be not a part for the Mixxx resources.

Do you see such a strings in the working system?

[Stéphane Guillou (stephane-guillou)]

1. I tried with Shade in mixxx.cfg, and it still crashes (see attachment "valgrind --tool=memcheck --leak-check=yes with shade output")

2. The line:
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
... is also in the output on the working installation, as PulseAudio is not installed by default on KXStudio. Mixxx still works fine, I use it with Jack. (See following attachment "working machine output of valgrind --tool=memcheck mixxx")

Is there an issue with the translation? I know I had my system in French at some stage and some relics remain here and there for some reason, but surely this is not what the problem comes from, right?

[Daniel Schürmann (daschuer)]

No Idea so far.

Maybe you can single step though the code and watch the memory usage on each step.
Or just add a breakpoint at qDebug() and see when the memory usage rises.
You may add additional qDebug() statements in the startup code.

[Stéphane Guillou (stephane-guillou)]

Update: I do not have the issue anymore, Mixxx starts fine now. Not sure which update did it, but it was something between my last comment (4th of December) and today. As I tried to step through with gdb, it went through without a problem. I can start it from the launcher directly too.

Build that I am using: 2.0.0.1 (build 1.12 r5769)

[Stéphane Guillou (stephane-guillou)]

Anyway I can mark this as "worksforme" now, or something like that? What is the usual process?

[Sébastien BLAISOT (sblaisot)]

Marking it as Invalid (Not a Bug)

[Stéphane Guillou (stephane-guillou)]

Reopening this as the smooth start reported in a previous comment was only a one-off... Sadly, I have the problem again, extreme slow down and crash on startup, or complete hang.
I will try to step through once again.

[Stéphane Guillou (stephane-guillou)]

More recent gdb output

[Stéphane Guillou (stephane-guillou)]

more recent mixxx log

[Stéphane Guillou (stephane-guillou)]

Could someone please tell me how to figure out where to set the break point in gdb to step through the problematic function?

[Sean M. Pappalardo (pegasus-renegadetech)]

The problem does not appear to be in Mixxx at all. SIGKILL is sent to a process by another and Mixxx is just obeying. (Rather the OS is forcing it to.) As Daniel said, this is most likely due to memory pressure and your system is starting to kill processes taking up the most RAM to prevent a whole system hang.
To confirm, watch system monitor or run top (and press s then 1) and watch the memory usage as you start Mixxx in another window.

[Sean M. Pappalardo (pegasus-renegadetech)]

For example, on my 64-bit Debian 8 system with 8GB RAM, Mixxx takes up 3.7% of it (or about 305MB) on startup, without even loading a track.

[Daniel Schürmann (daschuer)]

After start on Ubuntu Precise:
Mixxx 2.0.0 + Shade = 117 MB
Mixxx 2.0.0 + LateNight = 117 MB
Mixxx 2.0.0 + Deere = 202 MB

[Daniel Schürmann (daschuer)]

If there is a memory eater it will be pretty hard to find.
One guess is the Waveforms or the skins.
You may start Mixxx with an empty Skin file to check it.
Than you may exclude some suspicious parts from Mixxx to track it down.

I have no experience with some of these tools, but maybe they help:
http://valgrind.org/docs/manual/ms-manual.html
https://courses.cs.washington.edu/courses/cse326/05au/valgrind-doc/ms_main.html
https://wiki.qt.io/Profiling_and_Memory_Checking_Tools

[Stéphane Guillou (stephane-guillou)]

Thank you both for your help.

I thought I'd try purging + reinstalling mixxx, but it didn't help. I then tried to purge mixxx, delete my .mixxx folder, and then reinstall it, and the problem is now gone.

Marking it as invalid again.

[Daniel Schürmann (daschuer)]

scary .. :-/

[Sean M. Pappalardo (pegasus-renegadetech)]

I wonder if there was file corruption in your library database? (.mixxx/mixxxdb.sqlite)

[Stéphane Guillou (stephane-guillou)]

Actually, I lied, it is still here. It is definitely fairly variable. It managed to finally launch Mixxx (2.0.0.1-git5769-ppa1~trusty1, same as before) today, but the system is super slow, and the ksysguard shows that Mixxx uses about 2.8 GiB of memory.
Attached are today's terminal output (command is simply "mixxx", no flags or anything) and the corresponding log.

[Stéphane Guillou (stephane-guillou)]

... and the log.

Note that mixxx starts hogging memory when the following line appears:

Warning [Main]: Requested control does not exist: "[Vinylcontrol],show_vinylcontrol" Creating it.

(which is the last line in logs when mixxx is killed by the system)

Could it be that the "leak" happens during the "process" that results in the following line?

Debug [Main]: "Error: Unable to import console: no such extension"

[RJ Skerry-Ryan (rryan)]

Does this still occur with Mixxx 2.1.4?

[Stéphane Guillou (stephane-guillou)]

Hi rryan

All good now, I just tested: 2.1.4 starts snappy, and does not hog memory (about 300 mb).

Thanks for checking back! :)

[RJ Skerry-Ryan (rryan)]

Great, thanks for checking!

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8318