1.12beta1 hangs after about 2 hours worth of playback

[Bjoern K.]

Version: Mixxx 1.12.0-beta1 git 1.12 r5495
Operating System: Arch Linux
Laptop: IBM T61 (Core Duo 2.5 GHz, 2 GB RAM, 120GB SSD)
Controller: Behringer CMD Micro
Sound Card: Behringer UCA202 (USB)

I run Mixxx as root from a terminal.

During a gig yesterday, Mixxx hung on me during playback twice, each after about two hours worth of playback and controller use.

Started at 10pm, played music for an hour and then stopped due to a band playing. Played three tracks after the first band was done to cover the pause needed for switching out equipment on stage. Second band played until about 1am. During the time the bands played, the laptop and Mixxx were running, but idle.
Resumed DJ-ing until, after about 20 minutes (at around 1:20am, didn't note the exact time), Mixxx hung/froze during playback of a song. The sound stopped and Mixxx crashed after clicking the UI. Restarted it and all was fine again until about 3:28am when the same thing happened, only with a different song.
In both cases, the mp3s in question were played fine before by Mixxx, so corrupted mp3s are unlikely.
During the entire gig, the laptop was connected to AC power with the battery in as backup, so freezes due to power changes are unlikely as well.

Tried looking into the log files crested by mixxx, but they're not really helpful to me (no indications to pinpoint when something happened).

For what it's worth, I've attached my settings files and logs (from /root/.mixxx).

[Be (be.ing)]

> I run Mixxx as root from a terminal.
Can you reproduce this issue when running as an unprivileged user?

[Bjoern K. (amusing-random-alias)]

Okay, update.

What I did:
- Update the Mixxx 1.12beta1 branch
- Created a new, non-root profile for Mixxx
- Carried over my database and analysis folder
- Launched Mixxx via XFce's main menu after removing pasuspender from the shortcut

The setup was the same as above minus me being in the club. (I've tested at home.)

The error happened after an hour worth of playback this time.
Mixxx' UI hung, playback froze, I clicked it and the program crashed to desktop.

I'll attach my settings and the logs later.

Btw: This is the Arch Repository version I'm using.
https://aur.archlinux.org/packages/mixxx1.12-git/

[Bjoern K. (amusing-random-alias)]

Here's the logs and config file.

I'm running a second session at the moment with GDB in the background. I hope the crash occurs again after an hour; not too inclined to spend all night being all nervous about instabilities. *Ahem*

[Bjoern K. (amusing-random-alias)]

Two and a half hours of failure free playback and no error. Probably jinxed myself.

Regardless, I think I might chicken out of 1.12 for now. Got a gig coming up and don't want the added risk of Mixxx deserting me.

[Daniel Schürmann (daschuer)]

I do not see any suspicious entries in the log file, except that it just stops.

What happens with log.3 was this an other crash?

We have some known crashes caused by faulty files.
Not sure, if it is related Bug #1411479

To check this you start mixxx in gdb and play the tracks again that might cause the track.
Or you rename your mixxxdb.sqlight and restart Mixxx with gdb and
analyse your whole library.
At leased this procedure guarantees that you are not effected by Bug #1411479

[Daniel Schürmann (daschuer)]

Bug #1411479 happens during the library scan. So this might be unrelated.

[Owen Williams (ywwg)]

It's more likely that this is a corrupted track than anything else. The logs should show what track(s) were playing at the time of the crash, try playing those tracks again all the way through and see if that triggers the hang.

[Bjoern K. (amusing-random-alias)]

The library scans never gave me trouble, so it's definitely not #1411479. Also, it never crashed on the same song.

As for log.3, I have no idea. I'd have an idea if it were timestamped...

Some other things to consider:
- I have my mp3s stored on a USB pen drive. Are there any known issues with caching or USB autosuspend or so?
I assume that Mixxx stores the currently played song in RAM. What would happen if I have a song playing and request USB access while the drive is suspended. The RFA causes a CPU spike which makes the audio buffer underflow. Mixxx gets confused by accessing the library and having to fill the audio buffer and calls it quits. Plausible or safeguarded against?

- The build is done with "CPU optimization" enabled. Any known bugs there?

- The crash was always near, or slightly after, a full hour of playback. Anything taking place after an hour? Logfile flushing, GL rendering buffer flushing or anything else? Maybe in combination with item #1?

Also, can I herewith request an inprovement to the logging system?
Or at least have a working shortcut to start GDB and Mixxx with all relevant input parameters from console?

[Bjoern K. (amusing-random-alias)]

Owen: The tracks have nothing to do with this. I've played each of them more than once before and after the crashes and they worked just fine.

[Owen Williams (ywwg)]

Mixxx does not have any time-based garbage collection that would take place after an hour... some sort of power saving on the USB stick seems more likely. Does your OS have an option to power down inactive hard drives? Maybe try disabling that.

[Bjoern K. (amusing-random-alias)]

Disabling USB Autosuspend isn't much of a problem via PowerTOP.

Reverted to 1.11 for now.

The last 1.12 version I've used was an alpha from GIT around mid-december. Worked without a single crash.
What big (repeat: big!) changes were there between december and now?

[Owen Williams (ywwg)]

The only way we'll be able to track this bug down is by getting a good backtrace and reproducing the error: http://www.mixxx.org/wiki/doku.php/creating_backtraces

If you could reinstall 1.12 briefly and help us get a trace that would be a huge help, otherwise we have no way to fix the bug because none of us can reproduce the problem.

[Daniel Schürmann (daschuer)]

Starting mixxx with arguments under gdb works like this:
gdb --args mixxx --resourcepath res

I have no good idea how we can provide a better way to start it. Maybe we should add a crash report facility directly to mixxx instead.

The log files have reasonable file modify times maybe that helps to remember what has happened.

Mixxx caches only parts of the track in ram. You may try to remove your USB stick during playback to test it. As long you have your settings path on a fixed drive nothing bad school happen. Mixxx should play until the cache is empty without any crash.

On other issue comes my mind. We have a serious memory consumption issue starting mixxx with the developer flag. The same was reported with old versions of the Intel graphics driver. Maybe mixxx is killed by the os because of reaching memory limits. Please have a look if the used ram is increasing during a run.

[Bjoern K. (amusing-random-alias)]

Owen:
I already have GDB installed and was running it with 1.12 beta (see #5), but did not get any crash whatsoever.
The next opportunity to try 1.12 is tomorrow or next week. I've got a gig this evening and can't afford any software-based shenanigans whatsoever.

Daniel:
That command only starts GDB. You still have to issue a "run" command to start Mixxx.

A crash reporter would be a good idea. Or a watchdog process in the background that is started with Mixxx and stopped with the very last command at shutdown and that tracks any irregularities.

The file modify time is a useless feature in Thunar as it only discriminates between days and not hours or minutes. And I never can remember too many console commands to grep (or so) for a file change date.

Caching only parts?
Is that a feature to support excessively huge files (.flac)? Did this ever give trouble with USB autosuspend?
Is track caching constantly improved upon or was this carried over largely unchanged from 1.11?

I did not run 1.12 with the -devel flag, but I also did not track memory consumption either.
The T61 has 2 GB RAM and a dedicated GPU (NVidia Quadro somethingsomething with the legacy 340.x driver).
Arch uses the x86 build on the laptop. What's the limit at which a process will be suspended by the kernel due to excessive memory demands?

[Daniel Schürmann (daschuer)]

The modification time of mixxx.log.3 is 2015-07-05 03:28

> Did you ever hade trouble with USB autosuspend?

I do not know any issues. IMHO it works without any disturbance and shout auto-unsuspend if required.
Do you have any issues like short dropouts with that?

> Is track caching constantly improved upon or was this carried over largely unchanged from 1.11?

We did dome changes in that code, since 1.11. But the main principals are still like 1.11.

> What's the limit at which a process will be suspended by the kernel due to excessive memory demands?

It spends a process only if almost all memory is gone. Mixxx should consume not more than 500 MB.
But the absolute size is not relevant here. Once the used memory is growing without a stop, it will reach any limit and crashes finally.

I do not know a memory leaking issue with NVidida though.
The known issue happens only with the --developer flag active or old Intel graphics driver.

[Bjoern K. (amusing-random-alias)]

Had some time for 1.12 this evening. GDB in the background and all. Downloaded the latest source from the 1.12 beta branch and compiled it.

Pretended to play a set, but mucked about in the background, i.e. copying mp3s, updating the library, etc, etc...for two and a half hours.

No crash. No crash at all.

I don't get it.

[Owen Williams (ywwg)]

going to mark as incomplete for now, please report back if this happens again.

[Bjoern K. (amusing-random-alias)]

Will do. Thanks for the assistance so far.

[Bjoern K. (amusing-random-alias)]

Had a spontaneous "productive" gig tonight and the Mixxx beta (not a recent GIT bulid but a newer one than the one that I had the problem with) ran flawlessly.
So it seems that this might have been a one-in-a-time problem.

I'll be running any future beta build from GDB regardlessly lest I end up without a usable log again.

[Swiftb0y (swiftb0y)]

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