QGLShader::link: Fragment shader(s) linked.... Crash on startup

[Albert Santoni]

Mixxx 1.8.0~beta1 crashes on startup on Windows Vista after it has created the UI and is starting to initialize OpenGL (or something like that), with the following error:

QGLShader::link: "Fragment shader(s) linked, vertex shader(s) linked."

I think it's a Qt 4.6 bug: http://bugreports.qt.nokia.com/browse/QTBUG-6947
That bug appears to be fixed in Qt 4.6.1.

Sean, you're going to hate me for this, but can you rebuild again Qt 4.6.1 and we'll see if Mixxx runs?

Thanks,
Albert

[Sean M. Pappalardo (pegasus-renegadetech)]

It's already packaged with Qt 4.6.1 :S

[Adam Davison (adamdavison)]

Hey guys. I think I saw this before. They're only qWarnings but
because we catch them and pop up a dialog box inside the repaint
thread it breaks everything.

If you turn off those popups it works if I remember correctly...

On 5 Feb 2010, at 05:58, Pegasus <email address hidden> wrote:

> It's already packaged with Qt 4.6.1 :S
>
> --
> QGLShader::link: Fragment shader(s) linked.... Crash on startup
> https://bugs.launchpad.net/bugs/517373
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.

[Albert Santoni (gamegod)]

Fixed in trunk. Adam get's the points for this.

[Sean M. Pappalardo (pegasus-renegadetech)]

Careful...the whole reason we added errorDialog is so that when threads other than the main one issue a qWarning or qCritical, the GUI thread would pop up the message box. (Otherwise Qt complains about it being in the wrong thread, the box with the real error doesn't paint, and the user has no idea what happened a la v1.6.x.)

Also take note that many of the errors people have reported with the first beta package were screen grabs of the qWarning boxes. (Even though the messages are logged, many of our users have difficulty finding mixxx.log, so showing a dialog is preferable to Mixxx just starting to act flaky, because then it just appears buggy.)

RJ mentioned the core problem with this bug is that Qt happens to be in an OpenGL context when another GUI function (QMessageBox) was called, causing it to hang. I'm thinking a better solution would be to add a flag to errorDialog that suppresses the QMessageBoxes. Then in our GUI setup code, we'd fire a signal to tell errorDialog to keep quiet until we're done setting up the GUI and tell it again when we're done.

Thoughts?

[Sean M. Pappalardo (pegasus-renegadetech)]

Also, errorDialog attempts graceful shutdown when possible on qCriticals (so settings get saved, etc.)

[RJ Skerry-Ryan (rryan)]

On Mon, Feb 8, 2010 at 6:50 AM, Pegasus <email address hidden> wrote:
>
> RJ mentioned the core problem with this bug is that Qt happens to be in
> an OpenGL context when another GUI function (QMessageBox) was called,
> causing it to hang. I'm thinking a better solution would be to add a
> flag to errorDialog that suppresses the QMessageBoxes. Then in our GUI
> setup code, we'd fire a signal to tell errorDialog to keep quiet until
> we're done setting up the GUI and tell it again when we're done.
>
> This hack would work for this specific case. What happens when Qt 4.7
qWarnings every time we do something like draw the waveform. Every install
of Mixxx would be boned because it would constantly be popping up modal
boxes. We have to get rid of the idea of misusing the logging system for GUI
reporting. Every piece of Mixxx that needs to report something to a user
about some kind of error condition needs to use some Mixxx way to do it, not
a Qt way to do it.

Here's one way to do it. Make ErrorDialog a singleton class. Add a static
'critical()' and 'warning()' method to the class which calls similar
singleton methods. The signals that are already in place ensure the message
gets proxied to the GUI thread. Change every instance of qWarning and
qCritical in Mixxx (there are something like 10-20 total) to use
ErrorDialog.

[Albert Santoni (gamegod)]

Ok, I have a few beefs:

- Blocking the GUI thread's event loop with ErrorDialog is having some
catastrophic effect. Whether it's a race condition or something else,
we don't know.
- We should use show() instead of exec() to try to get around this.
- We still don't want to use a message box for qWarning() because it's
getting fired for non-critical warnings. You don't want this popping
up in the middle of your DJ set.
- We can still show messageboxes for qCritical() though.

I can make these changes later today to fix this up...

Thanks,
Albert

On Mon, Feb 8, 2010 at 3:50 AM, Pegasus <email address hidden> wrote:
> Careful...the whole reason we added errorDialog is so that when threads
> other than the main one issue a qWarning or qCritical, the GUI thread
> would pop up the message box. (Otherwise Qt complains about it being in
> the wrong thread, the box with the real error doesn't paint, and the
> user has no idea what happened a la v1.6.x.)
>
> Also take note that many of the errors people have reported with the
> first beta package were screen grabs of the qWarning boxes. (Even though
> the messages are logged, many of our users have difficulty finding
> mixxx.log, so showing a dialog is preferable to Mixxx just starting to
> act flaky, because then it just appears buggy.)
>
> RJ mentioned the core problem with this bug is that Qt happens to be in
> an OpenGL context when another GUI function (QMessageBox) was called,
> causing it to hang. I'm thinking a better solution would be to add a
> flag to errorDialog that suppresses the QMessageBoxes. Then in our GUI
> setup code, we'd fire a signal to tell errorDialog to keep quiet until
> we're done setting up the GUI and tell it again when we're done.
>
> Thoughts?
>
> --
> QGLShader::link: Fragment shader(s) linked.... Crash on startup
> https://bugs.launchpad.net/bugs/517373
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[RJ Skerry-Ryan (rryan)]

On Mon, Feb 8, 2010 at 12:25 PM, Albert Santoni <email address hidden> wrote:

> Ok, I have a few beefs:
>
> - Blocking the GUI thread's event loop with ErrorDialog is having some
> catastrophic effect. Whether it's a race condition or something else,
> we don't know.
>
If anything, we know that it's related to popping dialogs on a warning Qt
has generated.

> - We should use show() instead of exec() to try to get around this.
>
On a critical, show() will popup the dialog for a millisecond or so -- until
exit(1) is called and it'll disappear. Modality makes sense for criticals,
not for warnings.

> - We still don't want to use a message box for qWarning() because it's
> getting fired for non-critical warnings. You don't want this popping
> up in the middle of your DJ set.
>
Can't agree more. None of our qWarning's are worth a modal popup.

   - 1 upgrade.cpp warning about MIDI file format
   - WWidget warning when a connected control does not exist
   - WWidget warning when the skin XML didn't parse correctly
   - misc ScriptStudio warning
   - 4 warnings in MidiMapping that happen on MIDI mapping load

DlgMidiMapping should be the thing in charge of telling the person that
something went wrong with loading the mapping. MidiMapping should have a way
of reporting its errors. This is as simple as threading a QStringList
 through its calls and returning a bool for success or not. Using qWarning
as a shortcut to get to the UI is not good.

Similarly the Dlg in charge of skin loading should similar functionality.

- We can still show messageboxes for qCritical() though.
>
> Here is every use of qCritical in Mixxx:

   - ConfigObject :: if config path is empty.. the world is FUBAR --
   reasonable
   - EngineVinylControl -- a FIXME .. -- albert, reasonable?
   - EngineBuffer -- basically an assert that should never happen --
   reasonable
   - MixxxApp -- skin directory does not exist -- reasonable
   - Syntax error in MIDI Script
   - Uncaught exception in MIDI Script
   - Problem opening MIDI Script

In no way do those MIDI script issues warrant quitting Mixxx. They warrant
reporting an error to a script debugger dialog a-la Firefox. Or popping up a
problem dialog in DlgMIDI when you load the mapping. How would you feel if
Firefox went down every time a website had a javascript error. I would
ragequit. The same should go for Mixxx :).

I agree -- keep qCritical as a 'cut-and-run' bail option -- but only for
situations that really warrant it.

I can make these changes later today to fix this up...
>
> Thanks,
> Albert
>
> On Mon, Feb 8, 2010 at 3:50 AM, Pegasus <email address hidden> wrote:
> > Careful...the whole reason we added errorDialog is so that when threads
> > other than the main one issue a qWarning or qCritical, the GUI thread
> > would pop up the message box. (Otherwise Qt complains about it being in
> > the wrong thread, the box with the real error doesn't paint, and the
> > user has no idea what happened a la v1.6.x.)
> >
> > Also take note that many of the errors people have reported with the
> > first beta package were screen grabs of the qWarning boxes. (Even though
> > the messages are logged, many of our users have difficult...

[Sean M. Pappalardo (pegasus-renegadetech)]

This all makes sense to me and I agree. Regarding the MIDI script errors, I've already changed qCriticals into friendly qWarnings unless running with --midiDebug in the script timers branch. One problem with using DlgMIDI to pop error dialogs is that some errors (like exceptions) don't occur on load but when the function is actually executed, so how can we let the user know to at least expect erratic behavior? (See r2274 of the features_scriptTimers branch and my related merge proposal comment.)

Obviously doing any of this this via our own messaging is the way to go. Can we implement it for 1.8?

[Sean M. Pappalardo (pegasus-renegadetech)]

This all makes sense to me and I agree. Regarding the MIDI script errors, I've already changed qCriticals into friendly qWarnings unless running with --midiDebug in the script timers branch. One problem with using DlgMIDI to pop error dialogs is that some errors (like exceptions) don't occur on load but when the function is actually executed, so how can we let the user know to at least expect erratic behavior? (See r2274 of the features_scriptTimers branch and my related merge proposal comment.)

Obviously doing any of this this via our own messaging is the way to go. Can we implement it for 1.8?

And it sounds like we should continue to use errorDialog for qCriticals.

[Sean M. Pappalardo (pegasus-renegadetech)]

For reference, the bug that prompted the addition of errorDialog: Bug #303804

[Sean M. Pappalardo (pegasus-renegadetech)]

Forum user just reported that this happens on Linux as well with Qt 4.6: http://mixxx.org/forums/viewtopic.php?f=3&t=1190

[Sean M. Pappalardo (pegasus-renegadetech)]

ErrorDialog has been extended in the features_messageBox branch so qWarning should no longer be used for user-facing dialogs. The relevant changes have been made to the MIDI subsystem in that branch, so once that branch is merged, this bug can be put to rest for good with no worries about future such bugs cropping up.

[Alexander Kops (alexkops)]

I just installed Mixxx from the Ubuntu Lucid Lynx repositories and it's unfortunately unusable because of this bug.
It shows an empty "Mixxx - Warning" box on startup (which cannot be closed), freezing the main Mixxx-Window.
In the command line I get the mentioned "QGLShader::link: "Fragment shader(s) linked, vertex shader(s) linked." message.
Is there a way to prevent this warning (with a command line parameter maybe)?
Or could the version in the Ubuntu repositories be fixed to make this useable?

[Timo Witte (timo-witte)]

i can confirm this bug in Ubuntu lucid.

[Pablo Vanwoerkom (guikubivan)]

Me too on debian amd64 Squeeze

[nyarnon (cabal)]

Natty Narwal still has the bug. MIXXX ppa: also. Ridiculous.

[nyarnon (cabal)]

Someone should change the status this is not fixed at all.

[William Good (bkgood)]

Better to have this in the open bug queue rather than marked closed since a handful of people still seem to be experiencing it.

[Sean M. Pappalardo (pegasus-renegadetech)]

What version of Mixxx is in Natty and other Ubuntus? This was indeed fixed with Mixxx v1.8.0.

[William Good (bkgood)]

https://launchpad.net/mixxx/+packages

Natty has 1.8.2 so the bug appears to remain.

[Sean M. Pappalardo (pegasus-renegadetech)]

We actually fixed this when we stopped popping dialogs for qWarnings.

[Swiftb0y (swiftb0y)]

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