TagLib crashes while scanning recording

Bug #1166267 reported by J A Brown
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Critical
Unassigned
1.10
Won't Fix
Critical
Unassigned
1.11
Won't Fix
Critical
Unassigned
2.0
Fix Released
Critical
Unassigned

Bug Description

Using Linux 12.10, Mixxx 1.10 Was attempting to record mix from auto dj - 2 hour long set, program crashed 3/4 or way through.

Revision history for this message
J A Brown (inisfad) wrote :
Download full text (9.3 KiB)

(Sorry, I don't know how to 'attach' a file. When Mixxx was finally able to load again, it would play one song half way through and then freeze. Log at time of freeze:
Debug [Main]: Mixxx 1.10.1 "(built on: Jun 30 2012 @ 15:56:52; flags: hifieq mad midiscript optimize=9 qdebug shoutcast verbose vinylcontrol)" is starting...
Debug [Main]: Qt version is: 4.8.1
Debug [Main]: Configuration file is at the current version 1.10.1
Debug [Main]: Loading translations for locale "en_IE" from translations folder "/usr/share/mixxx/translations/" : fail
Debug [Main]: Found folder 'Mixxx' within default OS music directory
Debug [Main]: Could not create folder 'Recordings' within 'Mixxx'
Debug [Main]: ControlObject::getControl returning NULL for ( "[Channel1]" , "vinylcontrol_mode" )
Debug [Main]: ControlObject::getControl returning NULL for ( "[Channel2]" , "vinylcontrol_mode" )
Debug [Main]: JACK client name set
Debug [Main]: Available QtSQL drivers: ("QSQLITE", "QMYSQL3", "QMYSQL")
Debug [Main]: src/library/trackcollection.cpp DB status: true
Debug [Main]: SchemaManager::upgradeToSchemaVersion already at version 13
Debug [Main]: TrackDAO::initialize QThread(0x98741c0, name = "Main") "qt_sql_default_connection"
Debug [Main]: CrateDAO::initialize()
Debug [Main]: CueDAO::initialize QThread(0x98741c0, name = "Main") "qt_sql_default_connection"
Debug [Main]: Promo dir: "/usr/share/mixxx//promo/1.8.0/index.html"
Debug [Main]: Traktor Library Location=[ "/home/jane/collection.nml" ]
Debug [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDepth" )
Debug [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDelay" )
Debug [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoPeriod" )
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: Constructed LibraryScanner
Debug [Main]: iTunes Album Art path is: ""
Debug [Main]: MidiDeviceManager::getDeviceList
Debug [Main]: Scanning PortMIDI devices:
Debug [Main]: Found output device # 0 Midi Through Port-0
Debug [Main]: Found input device # 1 Midi Through Port-0
Debug [Main]: Linking to output device # 0 "Midi Through Port-0"
Debug [Main]: Starting script engine with output device ""
Debug [MidiScriptEngine 1]: MIDI Device in script engine is: ""
Debug [Main]: MidiDeviceManager: Setting up devices
Debug [Main]: PortMIDI device "1. Midi Through Port-0" already closed
Debug [Main]: MidiMapping: Loading MIDI preset from "/home/jane/.mixxx/midi/Midi_Through_Port-0.midi.xml"
Debug [Main]: MidiOutputMappingTableModel::removeRows()
Debug [Main]: "Midi Through Port-0" settings found
Debug [MidiScriptEngine 1]: MidiScriptEngine: Loading & evaluating all MIDI script code
Debug [MidiScriptEngine 1]: MidiScriptEngine: Loading "/usr/share/mixxx/midi/midi-mappings-scripts.js"
Debug [Main]: MidiMapping: Input parsed!
Debug [Main]: MidiMapping: Output parsed!
Debug [Main]: Pr...

Read more...

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hm, this is a TagLib crash probably caused by a corrupt WAV/RIFF/AIFF file that is in your AutoDJ queue. Could you check each file in the queue and try to load it individually (without starting AutoDJ) to find which file it is?

Changed in mixxx:
importance: Undecided → Critical
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

If you do find the file that caused this could you please either post it here or email it to me? (<email address hidden>) so I can debug further. We may need to report this to TagLib. We have had issues like this in the past and TagLib fixed them. Those fixes should be in the version of TagLib packaged in Ubuntu 12.10 so I believe this is not the same though it is the same stack trace as Bug #1016726.

Revision history for this message
Sean M. Pappalardo (pegasus-renegadetech) wrote :

Egads, man. There's a link at the bottom that says "add attachment or patch"

description: updated
Revision history for this message
J A Brown (inisfad) wrote :

The original song of the crash was an mp3. Mixxx began to crash regardless of what song was loaded. And then crashed 30 seconds after starting the program, with no song loaded. If you are interested, I was posting the logs on the MIxxx forum - I was advised to download 1.11 which I did, and the same issue continued. Here is the link, if it's helpful:
http://www.mixxx.org/forums/viewtopic.php?f=3&t=4925

And Sean, thanks for the heads up. Sadly, as I started typing at the top, rather than at the bottom, I didn't see the link until everything was typed/copied. By that time, it was unlikely that I was going to start over.....

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

The song causing the crash is not necessarily the one loaded in a deck. So what might appear like random crashing on any song is actually just that Mixxx crashes when it scans the same problem song in the background.

It is also possible that a failed recording produced a corrupt file and every time Mixxx tries to read the metadata of this corrupt file it triggers the crash bug in TagLib.

Upgrading Mixxx isn't going to help because this is a taglib bug (it's very easy to see in the backtrace that this is the case).

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Could you try moving all the songs in your recordings folder out of that folder and see if Mixxx still crashes? If that fixes it then it's likely that we wrote a corrupt / half-done recording that causes TagLib to barf while trying to parse it.

Revision history for this message
J A Brown (inisfad) wrote :

By the way, a complete uninstall, deletion of configuration files and downgrade back to 1.10.1 has apparently solved whatever the issue was, as now Mixxx is back working as it should.

Revision history for this message
J A Brown (inisfad) wrote : Re: [Bug 1166267] Re: Mixxx crashes, makes computer unstable

Sorry, I am not terribly computer literate, however......I have had this
play list for about one month, and have been playing it again and again
without any issue. The files are either WAV, FLAC or MP3. The problem
arose yesterday when I attempted to record the entire mix - putting it
all into auto dj, and it crashed 3/4 of the way through. I have
completely uninstalled Mixxx and reinstalled it - this time my library
is only the specific playlist that I was using yesterday. Although I
have not played the entire playlist again, I have randomly played songs,
as well as the song that was on when the crash occurred, without issue.
> The song causing the crash is not necessarily the one loaded in a deck.
> So what might appear like random crashing on any song is actually just
> that Mixxx crashes when it scans the same problem song in the
> background.
>
> It is also possible that a failed recording produced a corrupt file and
> every time Mixxx tries to read the metadata of this corrupt file it
> triggers the crash bug in TagLib.
>
> Upgrading Mixxx isn't going to help because this is a taglib bug (it's
> very easy to see in the backtrace that this is the case).
>

Revision history for this message
J A Brown (inisfad) wrote : Re: Mixxx crashes, makes computer unstable
Revision history for this message
J A Brown (inisfad) wrote :

Seems my comment to the above file is not indicated?? After downloading a new Mixxx download, I only put songs from my playlist into the library, started Mixxx this morning, using Auto DJ and the record function. Mixxx crashed in the middle of the second song. Log is above as mixxx log tuesday. I then tried this, with the same songs, in the same order, without recording, and Mixxx crashed 30 seconds into the first song. Will attach the log for that below, as mixxx log tuesday 2.doc.

Revision history for this message
J A Brown (inisfad) wrote :
Revision history for this message
J A Brown (inisfad) wrote :

Now, trying this again, with latency set at 90 whatever, and manually loading the same first song into deck one, manually loading same second song into deck two, playing first song, about 30 seconds it, Mixxx crashes. Log attached below.

Revision history for this message
J A Brown (inisfad) wrote :
Revision history for this message
Daniel Schürmann (daschuer) wrote :

Hi JA,

Thank you for your logs.
Please do not attach Microsoft Word documents. They are unhandy.
Use Plain text (*.txt) instead or attach the mixxx.log itself.

Unfortunately the log file is not significant for your crash.

As RJ pointed out, from your back trace it is clear that the crash happens while reading meta data from a specific file.

I am not sure if you think this is still the case or not?
Maybe this bug is caused by two overlapping issues.
If you think this is still the issue I can prepare a version which will be more chatty in th log file when reading meta data.

In any case you should always run Mixxx inside GDB while testing to have the chance to produce an back trace .

Does the crash happens only with those specific songs, or can you trigger the crash with any songs?
Does Mixxx crash without playing?
Does Mixxx crash every time you try to play those songs?

I am currently working on a solution that a crash while reading meta date does not effect the whole Mixxx process.
It would be nice if you could mail, once identified mail your effected songs to <email address hidden>.
So I can test against this issue.

Thank you,

Daniel

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Thanks for providing more info JA -- in this case I believe the issue is probably that we have written a corrupt recording file and TagLib cannot process its metadata. Could you post the recordings from your recording folder so we can look at them? (or email them to us)

Revision history for this message
J A Brown (inisfad) wrote :

Mixxx now crashes within 50 seconds of loading the program. I do not have to be playing anything. Mixxx log attached

Revision history for this message
J A Brown (inisfad) wrote :
Download full text (7.6 KiB)

Mixxx log, as referenced above. Program was only loaded, nothing playing.

Debug [Main]: Mixxx 1.10.1 "(built on: Jun 30 2012 @ 15:56:52; flags: hifieq mad midiscript optimize=9 qdebug shoutcast verbose vinylcontrol)" is starting...
Debug [Main]: Qt version is: 4.8.1
Debug [Main]: Configuration file is at the current version 1.10.1
Debug [Main]: Loading translations for locale "en_IE" from translations folder "/usr/share/mixxx/translations/" : fail
Debug [Main]: Found folder 'Mixxx' within default OS music directory
Debug [Main]: Could not create folder 'Recordings' within 'Mixxx'
Debug [Main]: ControlObject::getControl returning NULL for ( "[Channel1]" , "vinylcontrol_mode" )
Debug [Main]: ControlObject::getControl returning NULL for ( "[Channel2]" , "vinylcontrol_mode" )
Debug [Main]: JACK client name set
Debug [Main]: Available QtSQL drivers: ("QSQLITE", "QMYSQL3", "QMYSQL")
Debug [Main]: src/library/trackcollection.cpp DB status: true
Debug [Main]: SchemaManager::upgradeToSchemaVersion already at version 13
Debug [Main]: TrackDAO::initialize QThread(0x9cb81c0, name = "Main") "qt_sql_default_connection"
Debug [Main]: CrateDAO::initialize()
Debug [Main]: CueDAO::initialize QThread(0x9cb81c0, name = "Main") "qt_sql_default_connection"
Debug [Main]: Promo dir: "/usr/share/mixxx//promo/1.8.0/index.html"
Debug [Main]: Traktor Library Location=[ "/home/jane/collection.nml" ]
Debug [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDepth" )
Debug [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDelay" )
Debug [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoPeriod" )
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: CachingReader using 4980736 bytes.
Debug [Main]: Constructed LibraryScanner
Debug [Main]: iTunes Album Art path is: ""
Debug [Main]: MidiDeviceManager::getDeviceList
Debug [Main]: Scanning PortMIDI devices:
Debug [Main]: Found output device # 0 Midi Through Port-0
Debug [Main]: Found input device # 1 Midi Through Port-0
Debug [Main]: Linking to output device # 0 "Midi Through Port-0"
Debug [Main]: Starting script engine with output device ""
Debug [MidiScriptEngine 1]: MIDI Device in script engine is: ""
Debug [Main]: MidiDeviceManager: Setting up devices
Debug [Main]: PortMIDI device "1. Midi Through Port-0" already closed
Debug [Main]: MidiMapping: Loading MIDI preset from "/home/jane/.mixxx/midi/Midi_Through_Port-0.midi.xml"
Debug [Main]: MidiOutputMappingTableModel::removeRows()
Debug [Main]: "Midi Through Port-0" settings found
Debug [MidiScriptEngine 1]: MidiScriptEngine: Loading & evaluating all MIDI script code
Debug [MidiScriptEngine 1]: MidiScriptEngine: Loading "/usr/share/mixxx/midi/midi-mappings-scripts.js"
Debug [Main]: MidiMapping: Input parsed!
Debug [Main]: MidiMapping: Output parsed!
Debug [Main]: Promo dir: "/usr/share/mixxx//promo/1.8.0/index.html"
Debug [Main]: loadSettings: 1 0 "SlowFade...

Read more...

Revision history for this message
J A Brown (inisfad) wrote :
Download full text (21.1 KiB)

Here, ran it again in gdb. While the program did not 'shut off', it froze. Output here:

jane@jane-laptop:~$ gdb mixxx
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/mixxx...(no debugging symbols found)...done.
(gdb)
(gdb) set height 0
(gdb)
(gdb) run
Starting program: /usr/bin/mixxx
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb7d03b40 (LWP 3726)]
[New Thread 0xb73ffb40 (LWP 3727)]
Debug [Main]: Mixxx 1.10.1 "(built on: Jun 30 2012 @ 15:56:52; flags: hifieq mad midiscript optimize=9 qdebug shoutcast verbose vinylcontrol)" is starting...
Debug [Main]: Qt version is: 4.8.1
Debug [Main]: Configuration file is at the current version 1.10.1
Debug [Main]: Loading translations for locale "en_IE" from translations folder "/usr/share/mixxx/translations/" : fail
Debug [Main]: Found folder 'Mixxx' within default OS music directory
Debug [Main]: Could not create folder 'Recordings' within 'Mixxx'
[New Thread 0xb69ffb40 (LWP 3728)]
[New Thread 0xb60c4b40 (LWP 3729)]
Debug [Main]: ControlObject::getControl returning NULL for ( "[Channel1]" , "vinylcontrol_mode" )
Debug [Main]: ControlObject::getControl returning NULL for ( "[Channel2]" , "vinylcontrol_mode" )
Debug [Main]: JACK client name set
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
[New Thread 0xb18c2b40 (LWP 3730)]
[Thread 0xb18c2b40 (LWP 3730) exited]
[New Thread 0xb18c2b40 (LWP 3731)]
[Thread 0xb18c2b40 (LWP 3731) exited]
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
[New Thread 0xb18c2b40 (LWP 3732)]
[Thread 0xb18c2b40 (LWP 3732) exited]
[New Thread 0xb18c2b40 (LWP 3733)]
[Thread 0xb18c2b40 (LWP 3733) exited]
[New Thread 0xb18c2b40 (LWP 3734)]
[Thread 0xb18c2b40 (LWP 3734) exited]
Debug [Main]: Available QtSQL drivers: ("QSQLITE", "QMYSQL3", "QMYSQL")
Debug [Main]: src/library/trackcollection.cpp DB status: true
Debug [Main]: SchemaManager::upgradeToSchemaVersion already at version 13
Debug [Main]: TrackDAO::initialize QThread(0x85b61c0, name = "Main") "qt_sql_default_connection"
De...

Revision history for this message
J A Brown (inisfad) wrote :
Download full text (26.3 KiB)

I feel like a scientist. Again, running in gdb, songs load up, first song plays but no waveform showing, second song starts, crash::

Thread 15 (Thread 0xaf912b40 (LWP 4181)):
#0 0x081207a7 in ?? ()
#1 0x0811f730 in ?? ()
#2 0x0812e0c2 in ?? ()
#3 0x08125d7d in ?? ()
#4 0x0832e840 in ?? ()
#5 0x08365182 in ?? ()
#6 0x0013a6a5 in ?? () from /usr/lib/i386-linux-gnu/libportaudio.so.2
#7 0x0013c66a in ?? () from /usr/lib/i386-linux-gnu/libportaudio.so.2
#8 0x0014521f in ?? () from /usr/lib/i386-linux-gnu/libportaudio.so.2
#9 0x03444d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#10 0x03382d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 14 (Thread 0xb0823b40 (LWP 4179)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x0344896b in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/libpthread.so.0
#2 0x0339064c in pthread_cond_wait () from /lib/i386-linux-gnu/libc.so.6
#3 0x00459029 in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4
#4 0x0045906f in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4
#5 0x03444d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0x03382d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 13 (Thread 0xb1024b40 (LWP 4178)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x033745f0 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0x03a9aa7b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0x03a8d0ae in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0x03a8d201 in g_main_context_iteration ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0x02c92887 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#6 0x02c5e50d in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#7 0x02c5e7a9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#8 0x02b4794c in QThread::exec() ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#9 0x0837c544 in ?? ()
#10 0x02b4ade0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#11 0x03444d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#12 0x03382d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 12 (Thread 0xb56ecb40 (LWP 4177)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x033723eb in read () from /lib/i386-linux-gnu/libc.so.6
#2 0x02df14c5 in ?? () from /usr/lib/i386-linux-gnu/libsndfile.so.1
#3 0x02df6c13 in ?? () from /usr/lib/i386-linux-gnu/libsndfile.so.1
#4 0x02dc6251 in sf_read_short () from /usr/lib/i386-linux-gnu/libsndfile.so.1
#5 0x08376eeb in ?? ()
#6 0x0814ed4c in ?? ()
#7 0x08150895 in ?? ()
#8 0x02b4ade0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#9 0x03444d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#10 0x03382d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 11 (Thread 0xb18c2b40 (LWP 4176)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x032c21df in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0x032c5825 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0x0321213d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib...

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hi again,

Thanks for the additional data. Every log file you have posted points to the same issue that I mentioned:

1) There is a corrupt audio file that Mixxx is reading.
2) This corrupt file might be a music file of yours or a previously recorded file in your recordings directory.
3) The crash is originating withing TagLib, which is one of Mixxx's dependencies.

As Daniel offered to do, we should get you a custom version of Mixxx that announces right before it reads the metadata of a file. This would help you pin down which of your files (or Mixxx recordings) is corrupt.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Once you've found the corrupt file, we can submit it to the TagLib developers so that they can fix the bug. Once they fix that bug it will prevent Mixxx from crashing on corrupt files like this in the future.

Revision history for this message
J A Brown (inisfad) wrote :

OK,so what should I do now? As my 'new' library does not contain the entirety of the music files on my computer, would this mean that the corrupt file is within the library (even though it is not in a current playlist)? Mixxx is crashing now whether it is playing, or playing random songs (ie not the same one causing the crash). Do you want my playlist forwarded to you?

Revision history for this message
J A Brown (inisfad) wrote :
Download full text (25.9 KiB)

Crashed with a song from Rhythmbox, not contained in playlist:

cue_38_position" )
Debug [Main]: createWaveformViewer()
Debug [Main]: WaveformViewerFactory :: Creating new visual waveform
Debug [Main]: WaveformViewerFactory :: Sharing existing GL context.
Debug [Main]: ControlObject::getControl returning NULL for ( "[Spinny2]" , "show_spinny" )
Warning [Main]: Requested control does not exist: "[Spinny2],show_spinny" . Creating it.
Debug [Main]: Making property binder for "visible"
Warning [Main]: Object::connect: No such slot QGroupBox::setProperty(const char*, const QVariant&) in src/skin/propertybinder.cpp:13
Debug [Main]: ControlObject::getControl returning NULL for ( "[Channel2]" , "hotcue_38_position" )
Debug [Main]: Displaying mixxx
Debug [Main]: Running Mixxx
Debug [Main]: RhythmboxFeature::activate()
[New Thread 0xa7effb40 (LWP 8357)]
Debug [Thread (pooled)]: importMusicCollection Thread Id: QThread(0x86e0030, name = "Thread (pooled)")
Debug [Thread (pooled)]: clearTable Thread Id: QThread(0x86e0030, name = "Thread (pooled)")
Debug [Main]: BaseTrackCache(0x87d6d50) updateIndexWithQuery took 12 ms
Debug [Main]: RhythmboxTrackModel(0x87d70d0) select() took 16 ms
Debug [Main]: WSearchLineEdit::restoreSearch( "" )
Debug [Thread (pooled)]: Rhythmbox table entries of ' "rhythmbox_playlist_tracks" ' have been cleared.
Debug [Thread (pooled)]: clearTable Thread Id: QThread(0x86e0030, name = "Thread (pooled)")
Debug [Thread (pooled)]: Rhythmbox table entries of ' "rhythmbox_library" ' have been cleared.
Debug [Thread (pooled)]: clearTable Thread Id: QThread(0x86e0030, name = "Thread (pooled)")
Debug [Thread (pooled)]: Rhythmbox table entries of ' "rhythmbox_playlists" ' have been cleared.
Debug [Main]: BaseTrackCache(0x87d6d50) updateIndexWithQuery took 8 ms
Debug [Main]: RhythmboxFeature::activate()
Debug [Main]: RhythmboxTrackModel(0x87d70d0) select() took 12 ms
Debug [Main]: WSearchLineEdit::restoreSearch( "" )
Debug [Main]: TrackDAO(0x876f4b8) addTracks took 1 ms to add 0 tracks
[New Thread 0x9a5ffb40 (LWP 8367)]
Debug [Thread (pooled)]: [Channel1] CachingReader::loadTrack() load failed for" "/home/jane/Music/My Music/Bobby Darin/Mack the Knife [Atco]/04 Beyond the Sea.wma" ", file invalid, unlocked reader lock
Debug [Main]: Failed to load track "/home/jane/Music/My Music/Bobby Darin/Mack the Knife [Atco]/04 Beyond the Sea.wma" "The file '/home/jane/Music/My Music/Bobby Darin/Mack the Knife [Atco]/04 Beyond the Sea.wma' could not be loaded."
[Thread 0xa7effb40 (LWP 8357) exited]
Debug [Main]: TrackDAO(0x876f4b8) addTracks took 174 ms to add 1 tracks
Debug [Main]: BaseTrackCache(0x87c41c0) updateIndexWithQuery took 1 ms
Debug [Main]: BeatFactory::loadBeatsFromByteArray could not parse serialized beats.
terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb18c2b40 (LWP 8338)]
0x00132416 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 22 (Thread 0x9a5ffb40 (LWP 8367)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x03448d13 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/libpt...

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Hi JA,

Thank you for your research :-)
I will prepare a version today and will provide you a download link when ready.

Revision history for this message
J A Brown (inisfad) wrote :

Thanks, Daniel. I guess there is no way for me to find out what 0x080721f4 and 0x080984e1 is from my end, eh?? :-).
Looking forward to your download link - I must say I am kind of enjoying this, it's like a mystery puzzle, and assume all will be ready for my 'event' in July. Thanks for your help.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1166267] Re: Mixxx crashes, makes computer unstable

I just changed Mixxx 1.11.0 so that when you run it with the --developer
flag it will print what files are being processed by TagLib before
processing them. This way when you see Mixxx crash the log file will tell
us which file was being processed.

It's in the 1.11 branch revision 3811. If you look here there should be
Ubuntu .deb files produced that you could try:
http://builds.mixxx.org/builds/release-1.11.x/r3811

You probably want the precise_i386 or precise_amd64 .deb files.

Run Mixxx with the "--developer" flag to turn on this logging and try to
get it to crash.

I just want to re-iterate -- Mixxx does things in the background. Just
because you loaded or didn't load a particular file (e.g. from Rhythmbox or
from a playlist) doesn't mean Mixxx will not crash by reading it. In
particular, files in your recording folder are processed by Mixxx at
startup so if a corrupt file is in there then it could cause Mixxx to crash
after a certain period of time regardless of whether you load a file.

Also, the crash is caused by you running out of memory. TagLib spins out of
control in an infinite loop until it consumes all available memory. This
means that when you load a problem track it could take minutes to hours
before the crash occurs depending on how much free memory you have.

On Tue, Apr 9, 2013 at 1:00 PM, J A Brown <email address hidden> wrote:

> OK,so what should I do now? As my 'new' library does not contain the
> entirety of the music files on my computer, would this mean that the
> corrupt file is within the library (even though it is not in a current
> playlist)? Mixxx is crashing now whether it is playing, or playing
> random songs (ie not the same one causing the crash). Do you want my
> playlist forwarded to you?
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1166267
>
> Title:
> Mixxx crashes, makes computer unstable
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1166267/+subscriptions
>

Revision history for this message
J A Brown (inisfad) wrote : Re: Mixxx crashes, makes computer unstable

Thanks for the info. Please advise of the following:

Do I uninstall the current Mixxx program prior to installing the new one, and if so, is uninstalling the old program through Ubuntu Software Center sufficient??

Will running the new Mixxx program with the --developer flag be self explanatory, or if not, where do I find this flag? Allow me to reiterate that I am not a programmer and have little experience in these matters. Thanks to advise!!

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1166267] Re: Mixxx crashes, makes computer unstable

I think that you should be fine with just installing the deb (it should
replace the old version) but uninstalling first in the software center is a
good idea just to make sure.

To enable the developer flag, just run Mixxx like you did with GDB before
except with --developer added when you type "run". Note there are two
dashes before developer.

1) gdb mixxx
2) run --developer

On Tue, Apr 9, 2013 at 4:12 PM, J A Brown <email address hidden> wrote:

> Thanks for the info. Please advise of the following:
>
> Do I uninstall the current Mixxx program prior to installing the new
> one, and if so, is uninstalling the old program through Ubuntu Software
> Center sufficient??
>
> Will running the new Mixxx program with the --developer flag be self
> explanatory, or if not, where do I find this flag? Allow me to
> reiterate that I am not a programmer and have little experience in these
> matters. Thanks to advise!!
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1166267
>
> Title:
> Mixxx crashes, makes computer unstable
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1166267/+subscriptions
>

Revision history for this message
Daniel Schürmann (daschuer) wrote : Re: Mixxx crashes, makes computer unstable

Thank you RJ for the patch! Just noticed that I have now twice the message on my system ;-)

@JA It should be possible to install the new version without remove the old. The Mint software center should do all the work for you. Just double click the *.deb file for your system.

If that not work for any reason you van install the *.deb from a terminal command line:
sudo dpkg -i mixxpackage.deb
replace mixxpackage.deb with the path to the just downloaded package.
Rightclick copy in nemo and Shift+Ctrl+V in terminal.

To start Mixxx in development mode you have to do it from command line as well:

just type:
mixxx --developer

Revision history for this message
J A Brown (inisfad) wrote :
Download full text (25.4 KiB)

OK, here's the gdb info:

#6 0x01d6b6b3 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0x0171cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#8 0x01b17d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 1 (Thread 0xb7fd1740 (LWP 19049)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x01b095f0 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0x01d55a7b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0x01d480ae in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4 0x01d48201 in g_main_context_iteration ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
#5 0x00357887 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#6 0x00678aaa in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
#7 0x0032350d in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#8 0x003237a9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#9 0x00328eba in QCoreApplication::exec() ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#10 0x005bda74 in QApplication::exec() ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
#11 0x08078e69 in ?? ()
#12 0x01a424d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#13 0x080a2d01 in ?? ()
(gdb)

Thread 23 (Thread 0xa723eb40 (LWP 19099)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x01720d13 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/libpthread.so.0
#2 0x002102df in QWaitCondition::wait(QMutex*, unsigned long) ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#3 0x00202474 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#4 0x0020fde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#5 0x0171cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0x01b17d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 22 (Thread 0xa854cb40 (LWP 19084)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x0172096b in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/libpthread.so.0
#2 0x00210350 in QWaitCondition::wait(QMutex*, unsigned long) ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#3 0x082e48f1 in ?? ()
#4 0x0020fde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#5 0x0171cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0x01b17d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 21 (Thread 0xa8d4db40 (LWP 19083)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x0172096b in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/libpthread.so.0
#2 0x00210350 in QWaitCondition::wait(QMutex*, unsigned long) ()
   from /usr/lib/i386-linux-gnu/libQtCore.so.4
#3 0x082e48f1 in ?? ()
#4 0x0020fde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#5 0x0171cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0x01b17d3e in clone () from /lib/i386-linux-gnu/libc.so.6

Thread 20 (Thread 0xa954eb40 (LWP 19082)):
#0 0x00132416 in __kernel_vsyscall ()
#1 0x0172096b in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/libpthread.so.0
#2 0x00210350 in QWaitCondition::wait(...

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1166267] Re: Mixxx crashes, makes computer unstable
Download full text (27.0 KiB)

Oops -- in this case we're looking for the log messages. The part of the
output that comes before typing "thread apply all bt". Could you post that?

On Tue, Apr 9, 2013 at 5:17 PM, J A Brown <email address hidden> wrote:

> OK, here's the gdb info:
>
> #6 0x01d6b6b3 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #7 0x0171cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> #8 0x01b17d3e in clone () from /lib/i386-linux-gnu/libc.so.6
>
> Thread 1 (Thread 0xb7fd1740 (LWP 19049)):
> #0 0x00132416 in __kernel_vsyscall ()
> #1 0x01b095f0 in poll () from /lib/i386-linux-gnu/libc.so.6
> #2 0x01d55a7b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #3 0x01d480ae in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #4 0x01d48201 in g_main_context_iteration ()
> from /lib/i386-linux-gnu/libglib-2.0.so.0
> #5 0x00357887 in
> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #6 0x00678aaa in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
> #7 0x0032350d in
> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib/i386-linux-gnu/libQtCore.so.4
> #8 0x003237a9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
> ()
> from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #9 0x00328eba in QCoreApplication::exec() ()
> from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #10 0x005bda74 in QApplication::exec() ()
> from /usr/lib/i386-linux-gnu/libQtGui.so.4
> #11 0x08078e69 in ?? ()
> #12 0x01a424d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
> #13 0x080a2d01 in ?? ()
> (gdb)
>
> Thread 23 (Thread 0xa723eb40 (LWP 19099)):
> #0 0x00132416 in __kernel_vsyscall ()
> #1 0x01720d13 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
> from /lib/i386-linux-gnu/libpthread.so.0
> #2 0x002102df in QWaitCondition::wait(QMutex*, unsigned long) ()
> from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #3 0x00202474 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #4 0x0020fde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #5 0x0171cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> #6 0x01b17d3e in clone () from /lib/i386-linux-gnu/libc.so.6
>
> Thread 22 (Thread 0xa854cb40 (LWP 19084)):
> #0 0x00132416 in __kernel_vsyscall ()
> #1 0x0172096b in pthread_cond_wait@@GLIBC_2.3.2 ()
> from /lib/i386-linux-gnu/libpthread.so.0
> #2 0x00210350 in QWaitCondition::wait(QMutex*, unsigned long) ()
> from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #3 0x082e48f1 in ?? ()
> #4 0x0020fde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #5 0x0171cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> #6 0x01b17d3e in clone () from /lib/i386-linux-gnu/libc.so.6
>
> Thread 21 (Thread 0xa8d4db40 (LWP 19083)):
> #0 0x00132416 in __kernel_vsyscall ()
> #1 0x0172096b in pthread_cond_wait@@GLIBC_2.3.2 ()
> from /lib/i386-linux-gnu/libpthread.so.0
> #2 0x00210350 in QWaitCondition::wait(QMutex*, unsigned long) ()
> from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #3 0x082e48f1 in ?? ()
> #4 0x0020fde0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #5 0x0171cd4c...

Revision history for this message
J A Brown (inisfad) wrote : Re: Mixxx crashes, makes computer unstable
Download full text (13.4 KiB)

Yup, here it is:

jane@jane-laptop:~$ gdb mixxx
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/mixxx...(no debugging symbols found)...done.
(gdb) set height 0
(gdb) run --developer
Starting program: /usr/bin/mixxx --developer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb7d06b40 (LWP 20768)]
[New Thread 0xb73ffb40 (LWP 20769)]
Debug [Main]: Mixxx 1.11.0 "(bzr r3811; built on: Apr 9 2013 @ 18:04:04; flags: bulk hid hifieq mad optimize=9 qdebug shoutcast vamp verbose vinylcontrol)" is starting...
Debug [Main]: Qt version is: 4.8.1
[New Thread 0xb69ffb40 (LWP 20770)]
Debug [StatsManager]: StatsManager thread starting up.
Debug [Main]: Configuration file is at the current version 1.11.0
Debug [Main]: Loading translations for locale "en_IE" from translations folder "/usr/share/mixxx/translations/" : fail
Debug [Main]: ConfigObject: Could not read ""
Debug [Main]: "/usr/share/mixxx/keyboard/en_GB.kbd.cfg" not found, using en_US.kbd.cfg
[New Thread 0xb61feb40 (LWP 20771)]
[New Thread 0xb4440b40 (LWP 20772)]
Warning [Main]: ControlObject::getControl returning NULL for ( "[Channel1]" , "vinylcontrol_mode" )
Warning [Main]: ControlObject::getControl returning NULL for ( "[Channel2]" , "vinylcontrol_mode" )
Debug [Main]: JACK client name set
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
[New Thread 0xafc3eb40 (LWP 20773)]
[Thread 0xafc3eb40 (LWP 20773) exited]
[New Thread 0xafc3eb40 (LWP 20774)]
[Thread 0xafc3eb40 (LWP 20774) exited]
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
[New Thread 0xafc3eb40 (LWP 20775)]
[Thread 0xafc3eb40 (LWP 20775) exited]
[New Thread 0xafc3eb40 (LWP 20776)]
[Thread 0xafc3eb40 (LWP 20776) exited]
[New Thread 0xafc3eb40 (LWP 20777)]
[Thread 0xafc3eb40 (LWP 20777) exited]
Warning [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDepth" )
Warning [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDelay" )
Warning [Main]: ControlObject::getControl returning NULL for ( "[Flang...

Revision history for this message
J A Brown (inisfad) wrote :

Wait, I think I screwed up. Am doing this again.....

Revision history for this message
J A Brown (inisfad) wrote :
Download full text (15.0 KiB)

Here:

jane@jane-laptop:~$ gdb mixxx
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/mixxx...(no debugging symbols found)...done.
(gdb) set height 0
(gdb) run --developer
Starting program: /usr/bin/mixxx --developer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb7d06b40 (LWP 21084)]
[New Thread 0xb73ffb40 (LWP 21085)]
Debug [Main]: Mixxx 1.11.0 "(bzr r3811; built on: Apr 9 2013 @ 18:04:04; flags: bulk hid hifieq mad optimize=9 qdebug shoutcast vamp verbose vinylcontrol)" is starting...
Debug [Main]: Qt version is: 4.8.1
[New Thread 0xb69ffb40 (LWP 21086)]
Debug [StatsManager]: StatsManager thread starting up.
Debug [Main]: Configuration file is at the current version 1.11.0
Debug [Main]: Loading translations for locale "en_IE" from translations folder "/usr/share/mixxx/translations/" : fail
Debug [Main]: ConfigObject: Could not read ""
Debug [Main]: "/usr/share/mixxx/keyboard/en_GB.kbd.cfg" not found, using en_US.kbd.cfg
[New Thread 0xb61feb40 (LWP 21087)]
[New Thread 0xb4440b40 (LWP 21088)]
Warning [Main]: ControlObject::getControl returning NULL for ( "[Channel1]" , "vinylcontrol_mode" )
Warning [Main]: ControlObject::getControl returning NULL for ( "[Channel2]" , "vinylcontrol_mode" )
Debug [Main]: JACK client name set
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
[New Thread 0xafc3eb40 (LWP 21092)]
[Thread 0xafc3eb40 (LWP 21092) exited]
[New Thread 0xafc3eb40 (LWP 21093)]
[Thread 0xafc3eb40 (LWP 21093) exited]
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib audio/pcm_bluetooth.c:1614:(audioservice_expect) BT_GET_CAPABILITIES failed : Input/output error(5)
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
[New Thread 0xafc3eb40 (LWP 21094)]
[Thread 0xafc3eb40 (LWP 21094) exited]
[New Thread 0xafc3eb40 (LWP 21095)]
[Thread 0xafc3eb40 (LWP 21095) exited]
[New Thread 0xafc3eb40 (LWP 21096)]
[Thread 0xafc3eb40 (LWP 21096) exited]
Warning [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDepth" )
Warning [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfoDelay" )
Warning [Main]: ControlObject::getControl returning NULL for ( "[Flanger]" , "lfo...

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Perfect! This is the offending file:

/home/jane/Music/New playlist/Mixxx/Recordings/2013-04-09_12h:26m:49s.wav

Could you post it here or email it to me (<email address hidden>)?

Revision history for this message
J A Brown (inisfad) wrote :

I must tell you that this is a bit weird. I believe that this recording file was done today, when I did a clean install of Mixxx, and tried to record my playlist again.
This entire issue started a couple of days ago, when I tried to record my 2 hour playlist. If you recall, the program worked and apparently recorded until 1 hour and 45 minutes into the playlist, when it then crashed. So is it possible that the problem is actually with the recording process?? This file is 36mb, and I can't email it. Will try uploading using the link below....If this doesn't work, can I compress it and send it??

Revision history for this message
J A Brown (inisfad) wrote :
Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1166267] Re: Mixxx crashes, makes computer unstable

As long as you compress it using a zip file or tar archive. If you compress
it into an MP3 or something then the corruption probably won't be
maintained.

It has happened before that Mixxx fails while recording and which leaves a
corrupt file in your recordings folder. When Mixxx starts up again it will
try to read this file. TagLib has a bug such that if it tries to read a
corrupt file like this, then it infinite loops and uses all the system
memory until Mixxx crashes while allocating memory.

On Tue, Apr 9, 2013 at 6:24 PM, J A Brown <email address hidden> wrote:

> I must tell you that this is a bit weird. I believe that this recording
> file was done today, when I did a clean install of Mixxx, and tried to
> record my playlist again.
> This entire issue started a couple of days ago, when I tried to record my
> 2 hour playlist. If you recall, the program worked and apparently recorded
> until 1 hour and 45 minutes into the playlist, when it then crashed. So is
> it possible that the problem is actually with the recording process?? This
> file is 36mb, and I can't email it. Will try uploading using the link
> below....If this doesn't work, can I compress it and send it??
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1166267
>
> Title:
> Mixxx crashes, makes computer unstable
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1166267/+subscriptions
>

Revision history for this message
J A Brown (inisfad) wrote :

I was able to upload it onto the website as a WAV file. Hopefully it's
ok. Let me know if there is anything further you want me to do - I am
in Ireland, so presumably some hours ahead of you - it's almost bedtime!!

I also wrote on the website that this issue actually started two days
ago, when I tried to record the entirety of my 2 hour play list. At 1
hour/45 minutes, the program crashed. So perhaps the issue is with
recording in some way??

Thanks for all your help.
Jane
> As long as you compress it using a zip file or tar archive. If you compress
> it into an MP3 or something then the corruption probably won't be
> maintained.
>
> It has happened before that Mixxx fails while recording and which leaves a
> corrupt file in your recordings folder. When Mixxx starts up again it will
> try to read this file. TagLib has a bug such that if it tries to read a
> corrupt file like this, then it infinite loops and uses all the system
> memory until Mixxx crashes while allocating memory.
>
>
> On Tue, Apr 9, 2013 at 6:24 PM, J A Brown <email address hidden> wrote:
>
>> I must tell you that this is a bit weird. I believe that this recording
>> file was done today, when I did a clean install of Mixxx, and tried to
>> record my playlist again.
>> This entire issue started a couple of days ago, when I tried to record my
>> 2 hour playlist. If you recall, the program worked and apparently recorded
>> until 1 hour and 45 minutes into the playlist, when it then crashed. So is
>> it possible that the problem is actually with the recording process?? This
>> file is 36mb, and I can't email it. Will try uploading using the link
>> below....If this doesn't work, can I compress it and send it??
>>
>> --
>> You received this bug notification because you are a member of Mixxx
>> Development Team, which is subscribed to Mixxx.
>> https://bugs.launchpad.net/bugs/1166267
>>
>> Title:
>> Mixxx crashes, makes computer unstable
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/mixxx/+bug/1166267/+subscriptions
>>

Revision history for this message
J A Brown (inisfad) wrote : Re: Mixxx crashes, makes computer unstable

Please be good enough to advise if, while waiting for the 'fix' for this issue, if I just delete this file, will I be able to use the program normally?? And, will I be able to record a set, or is the issue with actual recording?? Thanks.

Revision history for this message
J A Brown (inisfad) wrote :

Perhaps in the programmer's world, you are not supposed to thank someone for providing a fix for an issue, but I received an email last night that this issue had been fixed in the current release. So, thank you!

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: TagLib crashes while scanning file

I think we can call this fixed. TagLib's latest release does not crash on this file so Mixxx doesn't either.

Thanks J A Brown!

summary: - Mixxx crashes, makes computer unstable
+ TagLib crashes while scanning file
Changed in mixxx:
status: New → Fix Committed
status: Fix Committed → Fix Released
summary: - TagLib crashes while scanning file
+ TagLib crashes while scanning recording
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

BTW for others reading this report the resolution is to upgrade your version of TagLib.

Changed in mixxx:
status: Fix Released → Fix Committed
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.