Segmentation fault when closing MIxxx with a running Rhythmbox import

Bug #824171 reported by Daniel Schürmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Critical
Daniel Schürmann

Bug Description

This happens on my netbook with ubuntu lucid an with the current trunk 2840.
My desktop PC with ubuntu natty is not effected.

The attached patch solves the problem by cancelling the running import thread in the destructor.

Tags: crash
Revision history for this message
Daniel Schürmann (daschuer) wrote :
Changed in mixxx:
assignee: nobody → Daniel Schürmann (daschuer)
status: New → In Progress
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Presumably we will need a similar fix for iTunes and Traktor, since they are implemented in the same way as Rhythmbox.

tags: added: crash
Changed in mixxx:
importance: Undecided → High
milestone: none → 1.10.0
RJ Skerry-Ryan (rryan)
Changed in mixxx:
importance: High → Critical
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Daniel -- what about the following patch that just calls QFuture::cancel() and QFuture::waitForFinished() ? Could you test that this also fixes the segfault? I can't really reproduce since my imports go too quickly.

I think I prefer to just wait for the import to finish instead of threading a cancel boolean into the worker thread.

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

Daniel -- what about the following patch that just calls QFuture::cancel() and QFuture::waitForFinished() ? Could you test that this also fixes the segfault? I can't really reproduce since my imports go too quickly.

I think I prefer to just wait for the import to finish instead of threading a cancel boolean into the worker thread.

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

Hmm -- nevermind I see that QFuture's run via QtConcurrent::run() cannot be cancelled. Just the same, waiting for the future to finish should work fine -- right?

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

Hi RJ, when I was originally working on that bug, I had the same thoughts. I have pick the solution with the cancel boolean because on my netbook with a big Rhythmbox library, the import took about a minute and it is hard to explain, why the user should wait so long for building a temporary table when closing mixxx.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 824171] Re: Segmentation fault when closing MIxxx with a running Rhythmbox import

Daniel -- sounds good. I agree that not waiting is better if the import
takes a while. I'll fix up something similar for iTunes and Traktor then
commit your patch.

Thanks,
RJ

2011/10/14 Daniel Schürmann <email address hidden>

> Hi RJ, when I was originally working on that bug, I had the same
> thoughts. I have pick the solution with the cancel boolean because on my
> netbook with a big Rhythmbox library, the import took about a minute and
> it is hard to explain, why the user should wait so long for building a
> temporary table when closing mixxx.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/824171
>
> Title:
> Segmentation fault when closing MIxxx with a running Rhythmbox import
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/824171/+subscriptions
>

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

Thanks Daniel -- committed your patch and added similar protection for iTunes and Traktor.

Changed in mixxx:
status: In Progress → 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/5964

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.