"critical error" on startup with software gl renderer

Bug #1160353 reported by ewan colsell on 2013-03-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
High
Daniel Schürmann

Bug Description

mixxx 1.11 revision 3779 from bzr

i am running mixxx on avlinux 6.0(based on debian squeeze)
using an nvidia geforce fx 5200 (old card) using the nouveau gpl driver, (software renderer)

since i am using the software renderer, i suspect that this is not specific to my graphics card.

i have a laptop with an identical software configuration that does not suffer from this problem which uses an intel graphics card.

i DONT GET THIS PROBLEM WITH THE CLOSED SOURCE NVIDIA DRIVERS,

on startup i get a dialog box with "critical error" in its title but no text or buttons.

Debug [Main]: resize QSize(1024, 577)
Debug [Main]: Running Mixxx
Debug [Main]: ControllerManager::getControllerList
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Vertex shader for simpleShaderProg (MainVertexShader & PositionOnlyVertexShader) failed to compile
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Fragment shader for simpleShaderProg (MainFragmentShader & ShockingPinkSrcFragmentShader) failed to compile
Warning [Main]: QGLShaderProgram: could not create shader program
Critical [Main]: Errors linking simple shader: ""

Daniel Schürmann (daschuer) wrote :

Hi Ewan,

Does Mixxx crash?

It looks like Mixxx is configured for experimental GLSL Waveforms.

Please change your waveform settings in .mixxx/mixxx.cfg to

[Waveform]
WaveformType 0

and report the original value here.

This issue should be fixed since Bug #981218.
But maybe we have not cached all cases.

i have tried with WaveformType 0

but no change. still the exact same error.

since you ask my mixxx.cfg was like this:

[Waveform]
FrameRate 30
DefaultZoom 3
ZoomSynchronization 0
WaveformType 6
VisualGain_0 1.5
VisualGain_1 1
VisualGain_2 1
VisualGain_3 1
OverviewNormalized 0

On 26 March 2013 16:33, Daniel Schürmann <email address hidden> wrote:

> Hi Ewan,
>
> Does Mixxx crash?
>
> It looks like Mixxx is configured for experimental GLSL Waveforms.
>
> Please change your waveform settings in .mixxx/mixxx.cfg to
>
> [Waveform]
> WaveformType 0
>
> and report the original value here.
>
> This issue should be fixed since Bug #981218.
> But maybe we have not cached all cases.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1160353
>
> Title:
> "critical error" on startup with software gl renderer
>
> Status in Mixxx:
> New
>
> Bug description:
> mixxx 1.11 revision 3779 from bzr
>
> i am running mixxx on avlinux 6.0(based on debian squeeze)
> using an nvidia geforce fx 5200 (old card) using the nouveau gpl driver,
> (software renderer)
>
> since i am using the software renderer, i suspect that this is not
> specific to my graphics card.
>
> i have a laptop with an identical software configuration that does not
> suffer from this problem which uses an intel graphics card.
>
> i DONT GET THIS PROBLEM WITH THE CLOSED SOURCE NVIDIA DRIVERS,
>
>
> on startup i get a dialog box with "critical error" in its title but
> no text or buttons.
>
>
> Debug [Main]: resize QSize(1024, 577)
> Debug [Main]: Running Mixxx
> Debug [Main]: ControllerManager::getControllerList
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Vertex shader for simpleShaderProg (MainVertexShader &
> PositionOnlyVertexShader) failed to compile
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Fragment shader for simpleShaderProg (MainFragmentShader
> & ShockingPinkSrcFragmentShader) failed to compile
> Warning [Main]: QGLShaderProgram: could not create shader program
> Critical [Main]: Errors linking simple shader: ""
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
>

--
http://www.ewancolsell.com/

ewan colsell (ewanuno) wrote :

yes , mixxx crashes.

ewan colsell (ewanuno) wrote :

i have tried with WaveformType 0

but no change. still the exact same error.

since you ask my mixxx.cfg was like this:

[Waveform]
FrameRate 30
DefaultZoom 3
ZoomSynchronization 0
WaveformType 6
VisualGain_0 1.5
VisualGain_1 1
VisualGain_2 1
VisualGain_3 1
OverviewNormalized 0

Max Linke (max-linke) wrote :

please set the WaveformType to 0. It is still at 6 in your mixxx.cfg

If this still crashes could you also create a backtrace as described
here. This helps us see where exactly mixxx crashes

http://www.mixxx.org/wiki/doku.php/creating_backtraces

I'm not sure if this is a bug in nouveau though. This driver should
enable hardware rendering anyway.

On Tue, 26 Mar 2013 16:26:55 -0000
ewan colsell <email address hidden> wrote:

> i have tried with WaveformType 0
>
> but no change. still the exact same error.
>
> since you ask my mixxx.cfg was like this:
>
> [Waveform]
> FrameRate 30
> DefaultZoom 3
> ZoomSynchronization 0
> WaveformType 6
> VisualGain_0 1.5
> VisualGain_1 1
> VisualGain_2 1
> VisualGain_3 1
> OverviewNormalized 0
>

Daniel Schürmann (daschuer) wrote :

The error messages are initiated from QT itself.
/src/opengl/gl2paintengineex/qglengineshadermanager.cpp line 194.

I can hit the function with gdb when selecting GLWaveform = WaveformType 6. But not with EmptyWaveform = WaveformType 0

So if Mixxx still crashing with WaveformType 0 please provide the log and a backtrack as requested by Max.

ewan colsell (ewanuno) wrote :
Download full text (20.0 KiB)

sorry for the confusion, i really did set it to WaveformType 0 the config was for daniel who requested the previous config.

i should be more specific, it dosent segfault, it freezes while showing me an empty dialog box with "critical error' in its title.

here is a back trace:

Warning [Main]: QGLShader: could not create shader
Warning [Main]: Vertex shader for simpleShaderProg (MainVertexShader & PositionOnlyVertexShader) failed to compile
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Fragment shader for simpleShaderProg (MainFragmentShader & ShockingPinkSrcFragmentShader) failed to compile
Warning [Main]: QGLShaderProgram: could not create shader program
Critical [Main]: Errors linking simple shader: ""
^Z
Program received signal SIGTSTP, Stopped (user).
0xb7fe2424 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 16 (Thread 0xa6125b70 (LWP 5031)):
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb664f20a in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#2 0xb78c0572 in ?? () from /usr/lib/libQtCore.so.4
#3 0xb78bbaf2 in QMutex::lock() () from /usr/lib/libQtCore.so.4
#4 0x0807fdfa in QMutexLocker::relock (this=0xa6124cc8)
    at /usr/include/qt4/QtCore/qmutex.h:120
#5 0x0807fd76 in QMutexLocker (this=0xa6124cc8, m=0x855e928)
    at /usr/include/qt4/QtCore/qmutex.h:102
#6 0x08136fe2 in MessageHandler (type=QtDebugMsg,
    input=0xa9feefd0 "New BeatGrid ") at src/main.cpp:86
#7 0xb78b7f65 in qt_message_output(QtMsgType, char const*) ()
   from /usr/lib/libQtCore.so.4
#8 0x08077686 in ~QDebug (this=0xa6124d9c, __in_chrg=<value optimized out>)
    at /usr/include/qt4/QtCore/qdebug.h:85
#9 0x0825c1ae in BeatGrid (this=0xa9f72308, pTrack=0xad4c38b8,
    pByteArray=0x0, __in_chrg=<value optimized out>,
    __vtt_parm=<value optimized out>) at src/track/beatgrid.cpp:43
#10 0x08260e45 in BeatFactory::makeBeatGrid (pTrack=0xad4c38b8,
    dBpm=109.70999908447266, dFirstBeatSample=0)
---Type <return> to continue, or q <return> to quit---
    at src/track/beatfactory.cpp:35
#11 0x08259b76 in TrackInfoObject::setBpm (this=0xad4c38b8,
    f=109.70999908447266) at src/trackinfoobject.cpp:335
#12 0x0821ad44 in SoundSourceProxy::ParseHeader (p=0xad4c38b8)
    at src/soundsourceproxy.cpp:339
#13 0x08258f6e in TrackInfoObject::parse (this=0xad4c38b8)
    at src/trackinfoobject.cpp:198
#14 0x08257d5d in TrackInfoObject::initialize (this=0xad4c38b8,
    parseHeader=true) at src/trackinfoobject.cpp:142
#15 0x08256881 in TrackInfoObject (this=0xad4c38b8, sLocation=...,
    parseHeader=true) at src/trackinfoobject.cpp:43
#16 0x0817acb6 in TrackCollection::importDirectory (this=0x8baf528,
    directory=..., trackDao=..., nameFilters=..., cancel=0xa9f856ac)
    at src/library/trackcollection.cpp:158
#17 0x081da3c8 in LibraryScanner::recursiveScan (this=0xa9f855f8,
    dirPath=..., verifiedDirectories=...)
    at src/library/libraryscanner.cpp:379
#18 0x081da505 in LibraryScanner::recursiveScan (this=0xa9f855f8,
    dirPath=..., verifiedDirectories=...)
    at src/library/libraryscanner.cpp:404
#19 0x081da505 in LibraryScanner::recursiveScan (this=0xa9f855f8,
    dirPath=..., v...

Max Linke (max-linke) wrote :

In your config set show_spinny to zero at every occurence , their should be 2

The main problem here is in noveau (google give a lot of error with your card), but mixxx should also fail more gracefully when we the spinny widgets fail

Daniel Schürmann (daschuer) wrote :

Ok, I think I have narrowed it down.

The deadlock is, is caused by Mixxx itself, because it tries to display the "Critical Error" Message Box from the Shinny Paint event.
This causes a a new Spinny paint event. A paint event within a paint event seams to lead to a deadlock.

We exit Mixxx in any case on after closing the critical error message so the deadlock problem is a minor one.
An without the deadlock we where not able to get such a significant backtrace :-).

So I will try Max's idea to check http://qt-project.org/doc/qt-4.8/qglwidget.html#isValid before painting.

Changed in mixxx:
assignee: nobody → Daniel Schürmann (daschuer)
status: New → In Progress
importance: Undecided → High
RJ Skerry-Ryan (rryan) wrote :

Nice work! We've had an issue like this before related to the waveforms in
a much older version of Mixxx. I can't seem to find the bug report though.

On Thu, Apr 4, 2013 at 9:01 AM, Daniel Schürmann <<email address hidden>
> wrote:

> Ok, I think I have narrowed it down.
>
> The deadlock is, is caused by Mixxx itself, because it tries to display
> the "Critical Error" Message Box from the Shinny Paint event.
> This causes a a new Spinny paint event. A paint event within a paint event
> seams to lead to a deadlock.
>
> We exit Mixxx in any case on after closing the critical error message so
> the deadlock problem is a minor one.
> An without the deadlock we where not able to get such a significant
> backtrace :-).
>
> So I will try Max's idea to check
> http://qt-project.org/doc/qt-4.8/qglwidget.html#isValid before painting.
>
>
>
> ** Changed in: mixxx
> Assignee: (unassigned) => Daniel Schürmann (daschuer)
>
> ** Changed in: mixxx
> Status: New => In Progress
>
> ** Changed in: mixxx
> Importance: Undecided => High
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1160353
>
> Title:
> "critical error" on startup with software gl renderer
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
>

RJ Skerry-Ryan (rryan) wrote :

Found it -- Bug #517373. This was because our warning handler would show a
message box on qWarning which would sometimes happen when a paint event was
already active. So that's not really related to what's going on here.

I agree we should fix that deadlock but like you said it won't actually fix
this bug because we were already in the qCritical handler which would have
aborted us. Is a shader link failure really a quit-worthy event? Is that
just because Qt qCritical's it? Maybe we should stop quitting Mixxx on
qCritical and just explicitly quit everywhere Mixxx has a qCritical that is
quit-worthy.

On Thu, Apr 4, 2013 at 10:25 AM, RJ Ryan <email address hidden> wrote:

> Nice work! We've had an issue like this before related to the waveforms in
> a much older version of Mixxx. I can't seem to find the bug report though.
>
>
> On Thu, Apr 4, 2013 at 9:01 AM, Daniel Schürmann <
> <email address hidden>> wrote:
>
>> Ok, I think I have narrowed it down.
>>
>> The deadlock is, is caused by Mixxx itself, because it tries to display
>> the "Critical Error" Message Box from the Shinny Paint event.
>> This causes a a new Spinny paint event. A paint event within a paint
>> event seams to lead to a deadlock.
>>
>> We exit Mixxx in any case on after closing the critical error message so
>> the deadlock problem is a minor one.
>> An without the deadlock we where not able to get such a significant
>> backtrace :-).
>>
>> So I will try Max's idea to check
>> http://qt-project.org/doc/qt-4.8/qglwidget.html#isValid before painting.
>>
>>
>>
>> ** Changed in: mixxx
>> Assignee: (unassigned) => Daniel Schürmann (daschuer)
>>
>> ** Changed in: mixxx
>> Status: New => In Progress
>>
>> ** Changed in: mixxx
>> Importance: Undecided => High
>>
>> --
>> You received this bug notification because you are a member of Mixxx
>> Development Team, which is subscribed to Mixxx.
>> https://bugs.launchpad.net/bugs/1160353
>>
>> Title:
>> "critical error" on startup with software gl renderer
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
>>
>
>

Daniel Schürmann (daschuer) wrote :

The attached patch checks if Wspinny is valid, if not an empty group widget is shown.
the patch is against lp:mixxx/1.11
You can add it with
bzr patch spinny_check.patch

Please search you mixxx.log for
WSpinny() and provide the whole line.

I would like to commit this patch in any case to 1.11 even if it does not fix the problem, because checking if WSinny is valid is a good idea anyhow. OK?

RJ Skerry-Ryan (rryan) wrote :

(again, ignoring the deadlock in the messagebox code -- we should still fix that)

Hi guys -- I think there really isn't a problem with the invalid QGLWidget here. Even if the QGLWidget is invalid it won't cause problems for us, the paint commands should just fail. The problem is that the Qt source code has qCritical() calls in it for debug output like failing to compile a shader. Qt doesn't expect that a qCritical will result in an exit or abort. This is something we do in Mixxx from src/errordialoghandler.cpp.

I propose that instead we remove exit/abort on qCritical from Mixxx and instead make every part of Mixxx that uses qCritical also exit explicitly if it wants to. Currently there are only 3 places that this happens:

1) If the ConfigObject config file cannot be found.
2) If the skin directory cannot be found.
3) If a script error occurs in debug mode.

I think case #3 should actually be removed in favor of a script console where developers can see the errors in their scripts.

If we don't remove the abort/exit on qCritical then some other Qt code that uses qCritical will cause us to crash in the future.

Max Linke (max-linke) wrote :

did you have something like this in mind?

RJ Skerry-Ryan (rryan) wrote :

Actually something a little more involved like this:

Max Linke (max-linke) wrote :

rryan - LGTM

Daniel - I think it would be better to display some text like 'video driver does not support openGL' when the dummy is shown instead of nothing. Otherwise people will think this feature is broken

RJ Skerry-Ryan (rryan) on 2013-04-04
Changed in mixxx:
milestone: none → 1.11.0
Daniel Schürmann (daschuer) wrote :

We have two aspects:

1. GL problem:
Ok, i will add a warning text.
I'm curious to hear if Ewan will ever see this message because I am wondering that the crash happens on that specific place in Qt.
@Ewan: You will find Linux builds including the patch in: http://builds.mixxx.org/builds/experimental-daschuers_trunk/r3178/
But be warned, its my experimental branch.

2. Deadlock
I have not looked to the details of RJs patch, but after a rough overview it looks good so far.

I have just read:
http://qt-project.org/doc/qt-4.8/qtglobal.html#qFatal
And it looks reasonable for me.

So Qt thinks:
qCritical = Continue
qFatal = Stop, if possible with debug

I would prefer we do the same: change our MIxxx reportCriticalErrorAndQuit to qFatal.
Then we are in line with Qt.
By the way: does our error handler disable the debugger invoke from the qfatal default handler?

The other problem to me is a major one: With the new ideas issued in the patch, we will not have such a fine bug reports like this in the future. We will only have users reporting some malfunction and then we have to look in the Mixxx log for a critical error but there is no way for the user to make a back trace.

Maybe we could route qCritical to qFatal in develloper mode and verifie that the qFatal default handler is called (or we can just write to NULL ;-))

RJ Skerry-Ryan (rryan) wrote :

I committed a fix for the deadlock -- it's a pretty simple one:
http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/release-1.11.x/revision/3797
MessageHandler's mutex is only meant to protect Logfile but it is held while calling ErrorDialogHandler (which is already thread safe) so that is why re-entrancy in MessageHandler can deadlock. The solution is to just unlock before calling ErrorDialogHandler.

RJ Skerry-Ryan (rryan) wrote :

I don't think the QGLWidget qCritical would actually cause a crash if it weren't for Mixxx deadlocking or quitting because someone issued a qCritical log. So there's really no crash to fix, just bad behavior on Mixxx's part. (We should confirm this with Ewan once we turn off quitting on qCritical).

RJ Skerry-Ryan (rryan) wrote :

I looked at the 3 places we call qFatal in Mixxx and I don't think any of them deserve that we quit -- we could instead handle the error gracefully.

RE: Debugging

I think the only reason we got a nice backtrace from Ewan was because Mixxx deadlocked. Normally on a qCritical/qFatal we would only see a backtrace leading up to the line the debug was issued from. We already know the line the debug was issued from because we can look where the error string occurs in the codebase. So the information the backtrace can tell us is:

1) The call stack leading up to the log message. (definitely useful in this case to see it was a deadlock!)
2) The state of all the other threads.

Since the qCritical will still issue an error dialog the user can use GDB to break and get a backtrace when the error dialog is issued. Since the error dialog is modal it preserves the call-stack that led up to the error dialog being displayed. I think it still allows the user to get us the information we need we just need to tell them how to break GDB using Control-C instead of waiting for a crash to occur.

ewan colsell (ewanuno) wrote :
Download full text (17.6 KiB)

ok here a new backtrace using the latest 1.11 bzr and the last few log messages,

now i get two critical error dialogs the frst says: 'error linking simple shader "" ' and the seccond says 'error linking blit shader ''' '

when i press ok in one of these dialogs mixx segfaults.

Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Debug [LibraryScanner 1]: New BeatGrid
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Debug [LibraryScanner 1]: New BeatGrid
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Debug [LibraryScanner 1]: New BeatGrid
Debug [LibraryScanner 1]: New BeatGrid
Debug [LibraryScanner 1]: New BeatGrid
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Debug [LibraryScanner 1]: New BeatGrid
Debug [LibraryScanner 1]: New BeatGrid

Program received signal SIGSEGV, Segmentation fault.
0xb6d520e0 in QGL2PaintEngineEx::renderHintsChanged() ()
   from /usr/lib/libQtOpenGL.so.4
(gdb) thread apply all bt

Thread 16 (Thread 0xa62e4b70 (LWP 3492)):
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb62e5c46 in statfs () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2 0xb62c1ca0 in pathconf () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#3 0xb79962f1 in ?? () from /usr/lib/libQtCore.so.4
#4 0xb7943e85 in ?? () from /usr/lib/libQtCore.so.4
#5 0xb7944a89 in ?? () from /usr/lib/libQtCore.so.4
#6 0xb7944f7f in QDirIterator::QDirIterator(QString const&, QFlags<QDir::Filter>, QFlags<QDirIterator::IteratorFlag>) () from /usr/lib/libQtCore.so.4
#7 0x081da55e in LibraryScanner::recursiveScan (this=0xa8701230,
    dirPath=..., verifiedDirectories=...)
    at src/library/libraryscanner.cpp:394
#8 0x081da5e1 in LibraryScanner::recursiveScan (this=0xa8701230,
    dirPath=..., verifiedDirectories=...)
    at src/library/libraryscanner.cpp:404
#9 0x081da5e1 in LibraryScanner::recursiveScan (this=0xa8701230,
    dirPath=..., verifiedDirectories=...)
    at src/library/libraryscanner.cpp:404
#10 0x081da5e1 in LibraryScanner::recursiveScan (this=0xa8701230,
    dirPath=..., verifiedDirectories=...)
    at src/library/libraryscanner.cpp:404
#11 0x081da5e1 in LibraryScanner::recursiveScan (this=0xa8701230,
    dirPath=..., verifiedDirectories=...)
    at src/library/libraryscanner.cpp:404
#12 0x081d99d5 in LibraryScanner::run (this=0xa8701230)
    at src/library/libraryscanner.cpp:227
#13 0xb78c0fbe in ?? () from /usr/lib/libQtCore.so.4
#14 0xb664ac39 in start_thread ()
   from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#15 0xb62f596e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6

Thread 15 (Thread 0xa86ffb70 (LWP 3491)):
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb664f20a in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/i386-linux-gnu/i...

RJ Skerry-Ryan (rryan) wrote :

Hey Ewan -- this isn't fixed yet so that crash is expected. The problem here is that when Qt writes a qCritical() message they never intended that that could stall execution inside the paint event and go for another round trip through the event loop (via ErrorDialogHandler and a modal QMessageBox) which in this case makes WSpinny's paintEvent re-entrant and multiple painters become active on the spinny.

RJ Skerry-Ryan (rryan) wrote :

(it's super useful to have the backtrace to confirm though -- thanks!)

RJ Skerry-Ryan (rryan) wrote :

Oh Daniel -- I may have misunderstood you re: debuggability. It's true that qCritical's that Qt issues would no longer result in a message box so we would lose the ability for users to easily get us backtraces when Qt does that.

Daniel Schürmann (daschuer) wrote :

Just added the patch from #12 with text "No openGL\nsupport." to lp:mixxx/1.11 revision 3800.

@ewan: please give it a try. If you still have the recursion, please provide the complete mixxx.log file, or at lest the few lines arround WSpinny().
Thank you!

RJ Skerry-Ryan (rryan) wrote :

I added my patch from #15 in lp:mixxx/1.11 r3802.

Daniel -- I don't think printing an error message in the skin is the right approach. In past Mixxx versions we have warned the user via a popup message box when their system doesn't support OpenGL and wouldn't have visuals when they run Mixxx. I think that's a better way.

When you insert it into the skin it might be invisible due to style sheets. The skinner has to account for the QLabel and style it via the style sheet. Also, the font sizes could mean the text is either too hard to read or too large. The artificial newline you put in the string might work for the skins we have but maybe wouldn't look right on a much larger spinny.

(Also it's a new string that won't be translated in time for 1.11.0...)

I think a more skin-integrated solution (for 1.12.x) would be for the spinny to have an inactive or disabled pixmap. If OpenGL was not present, we could swap it out for a static QPixmap of the inactive/disabled pixmap. In addition to this, a warning dialog about missing OpenGL support could warn the user in text that some features like waveforms and spinnies would be missing.

Daniel Schürmann (daschuer) wrote :

Hi RJ,

sorry for committing without a final go.
Let me explain why I was quite satisfied with the current solution:

* I do not like pop pup boxes that suddenly appear. The user is interrupted in it current use case. In this case he can simply disable spinnies to hide the text. Mixxx will work fine without openGL but without Spinnies
* The text is actually skinned, set by the background properties which is a QLable as well :-)
* This does not hurt even if you don't understand the complete message. The significant word openGL is international anyway.
* The skin designer should not worry about this issue, because he most likely is not able to check the dummy widget.
* this solution has less dependencies and less effort.
* the user can already see his openGL status below the waveform properties.
* not at least this solution was Max's idea which we both agreed

Now, I would wait for feedback from Ewan. But feel free to revert my commit. This is a corner case anyway, which is issued due to a bad driver setup.

Kind regards,

Daniel

Max Linke (max-linke) wrote :

I also like the idea of replacing the wspinny pixmap with a error text/pixmap instead of just a popup message.

by the way what is done with the waveforms when qt realises that openGL is not an option, do we fall back to the software renderer?

ewan colsell (ewanuno) wrote :

it's fixed! great work everybody.

the only waveforms that work for me are filtered-software and hsv (which is
a pit of a pink mess at the moment)

no spinnys obviously.

thanks!

On 6 April 2013 14:49, Max Linke <email address hidden> wrote:

> I also like the idea of replacing the wspinny pixmap with a error
> text/pixmap instead of just a popup message.
>
> by the way what is done with the waveforms when qt realises that openGL
> is not an option, do we fall back to the software renderer?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1160353
>
> Title:
> "critical error" on startup with software gl renderer
>
> Status in Mixxx:
> In Progress
>
> Bug description:
> mixxx 1.11 revision 3779 from bzr
>
> i am running mixxx on avlinux 6.0(based on debian squeeze)
> using an nvidia geforce fx 5200 (old card) using the nouveau gpl driver,
> (software renderer)
>
> since i am using the software renderer, i suspect that this is not
> specific to my graphics card.
>
> i have a laptop with an identical software configuration that does not
> suffer from this problem which uses an intel graphics card.
>
> i DONT GET THIS PROBLEM WITH THE CLOSED SOURCE NVIDIA DRIVERS,
>
>
> on startup i get a dialog box with "critical error" in its title but
> no text or buttons.
>
>
> Debug [Main]: resize QSize(1024, 577)
> Debug [Main]: Running Mixxx
> Debug [Main]: ControllerManager::getControllerList
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Vertex shader for simpleShaderProg (MainVertexShader &
> PositionOnlyVertexShader) failed to compile
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Fragment shader for simpleShaderProg (MainFragmentShader
> & ShockingPinkSrcFragmentShader) failed to compile
> Warning [Main]: QGLShaderProgram: could not create shader program
> Critical [Main]: Errors linking simple shader: ""
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
>

--
http://www.ewancolsell.com/

Daniel Schürmann (daschuer) wrote :

Hi Ewan, thank you for your feedback!

To answer Max's question from #28. Yes, we fall back to Software waveform in case of openGL absence.

Kind regards, Daniel

RJ Skerry-Ryan (rryan) wrote :

I agree it's not worth arguing about a corner case like this. Thanks for
the fix Daniel :).

I'm very curious whether an actual crash would occur if we didn't delete
the spinny. Ewan -- if I made you a custom binary without Daniel's patch to
delete the invalid spinny could you give ti a try?

On Sun, Apr 7, 2013 at 8:06 AM, Daniel Schürmann <<email address hidden>
> wrote:

> Hi Ewan, thank you for your feedback!
>
> To answer Max's question from #28. Yes, we fall back to Software
> waveform in case of openGL absence.
>
> Kind regards, Daniel
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1160353
>
> Title:
> "critical error" on startup with software gl renderer
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
>

ewan colsell (ewanuno) wrote :

sure, a patch would be fine too.

On 8 April 2013 01:08, RJ Ryan <email address hidden> wrote:

> I agree it's not worth arguing about a corner case like this. Thanks for
> the fix Daniel :).
>
> I'm very curious whether an actual crash would occur if we didn't delete
> the spinny. Ewan -- if I made you a custom binary without Daniel's patch to
> delete the invalid spinny could you give ti a try?
>
>
> On Sun, Apr 7, 2013 at 8:06 AM, Daniel Schürmann <
> <email address hidden>
> > wrote:
>
> > Hi Ewan, thank you for your feedback!
> >
> > To answer Max's question from #28. Yes, we fall back to Software
> > waveform in case of openGL absence.
> >
> > Kind regards, Daniel
> >
> > --
> > You received this bug notification because you are a member of Mixxx
> > Development Team, which is subscribed to Mixxx.
> > https://bugs.launchpad.net/bugs/1160353
> >
> > Title:
> > "critical error" on startup with software gl renderer
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1160353
>
> Title:
> "critical error" on startup with software gl renderer
>
> Status in Mixxx:
> In Progress
>
> Bug description:
> mixxx 1.11 revision 3779 from bzr
>
> i am running mixxx on avlinux 6.0(based on debian squeeze)
> using an nvidia geforce fx 5200 (old card) using the nouveau gpl driver,
> (software renderer)
>
> since i am using the software renderer, i suspect that this is not
> specific to my graphics card.
>
> i have a laptop with an identical software configuration that does not
> suffer from this problem which uses an intel graphics card.
>
> i DONT GET THIS PROBLEM WITH THE CLOSED SOURCE NVIDIA DRIVERS,
>
>
> on startup i get a dialog box with "critical error" in its title but
> no text or buttons.
>
>
> Debug [Main]: resize QSize(1024, 577)
> Debug [Main]: Running Mixxx
> Debug [Main]: ControllerManager::getControllerList
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Vertex shader for simpleShaderProg (MainVertexShader &
> PositionOnlyVertexShader) failed to compile
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Fragment shader for simpleShaderProg (MainFragmentShader
> & ShockingPinkSrcFragmentShader) failed to compile
> Warning [Main]: QGLShaderProgram: could not create shader program
> Critical [Main]: Errors linking simple shader: ""
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
>

--
http://www.ewancolsell.com/

RJ Skerry-Ryan (rryan) wrote :

Great -- thanks Ewan. Please apply this patch and let us know what happens / post a backtrace if you get a crash.

ewan colsell (ewanuno) wrote :

it works fine with the patch applied.

i just noticed though that with and without the patch i get a continuous
stream of the same error message on the console.:

Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not create shader
Warning [Main]: Warning: "" failed to compile!
Warning [Main]: QGLShader: could not ............

and so on until i quit mixxx.

On 9 April 2013 05:18, RJ Ryan <email address hidden> wrote:

> Great -- thanks Ewan. Please apply this patch and let us know what
> happens / post a backtrace if you get a crash.
>
> ** Patch added: "no_invalid_spinny_check.patch"
>
> https://bugs.launchpad.net/mixxx/+bug/1160353/+attachment/3633204/+files/no_invalid_spinny_check.patch
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1160353
>
> Title:
> "critical error" on startup with software gl renderer
>
> Status in Mixxx:
> In Progress
>
> Bug description:
> mixxx 1.11 revision 3779 from bzr
>
> i am running mixxx on avlinux 6.0(based on debian squeeze)
> using an nvidia geforce fx 5200 (old card) using the nouveau gpl driver,
> (software renderer)
>
> since i am using the software renderer, i suspect that this is not
> specific to my graphics card.
>
> i have a laptop with an identical software configuration that does not
> suffer from this problem which uses an intel graphics card.
>
> i DONT GET THIS PROBLEM WITH THE CLOSED SOURCE NVIDIA DRIVERS,
>
>
> on startup i get a dialog box with "critical error" in its title but
> no text or buttons.
>
>
> Debug [Main]: resize QSize(1024, 577)
> Debug [Main]: Running Mixxx
> Debug [Main]: ControllerManager::getControllerList
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Vertex shader for simpleShaderProg (MainVertexShader &
> PositionOnlyVertexShader) failed to compile
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Fragment shader for simpleShaderProg (MainFragmentShader
> & ShockingPinkSrcFragmentShader) failed to compile
> Warning [Main]: QGLShaderProgram: could not create shader program
> Critical [Main]: Errors linking simple shader: ""
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1160353/+subscriptions
>

--
http://www.ewancolsell.com/

RJ Skerry-Ryan (rryan) wrote :
Download full text (4.0 KiB)

Good to know -- glad it doesn't crash but it's probably good that we delete
it if it is invalid so that work is not wasted on trying to render it. What
happens if you choose a non-software GL renderer? Do your waveforms work?

Maybe we should make spinny's work more like the waveforms that have a
holder widget and a software vs. GL implementation so that spinny's could
work when OpenGL is not supported.

On Tue, Apr 9, 2013 at 11:58 AM, ewan colsell <email address hidden> wrote:

> it works fine with the patch applied.
>
> i just noticed though that with and without the patch i get a continuous
> stream of the same error message on the console.:
>
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not create shader
> Warning [Main]: Warning: "" failed to compile!
> Warning [Main]: QGLShader: could not ............
>
> and so on until i quit mixxx.
>
>
> On 9 April 2013 05:18, RJ Ryan <email address hidden> wrote:
>
> > Great -- thanks Ewan. Please apply this patch and let us know what
> > happens / post a backtrace if you get a crash.
> >
> > ** Patch added: "no_invalid_spinny_check.patch"
> >
> >
> https://bugs.launchpad.net/mixxx/+bug/1160353/+attachment/3633204/+files/no_invalid_spinny_check.patch
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1160353
> >
> > Title:
> > "critical error" on startup with software gl renderer
> >
> > Status in Mixxx:
> > In Progress
> >
> > Bug description:
> > mixxx 1.11 revision 3779 from bzr
> >
> > i am running mixxx on avlinux 6.0(based on debian squeeze)
> > using an nvidia geforce fx 5200 (old card) using the nouveau gpl
> driver,
> > (software renderer)
> >
> > since i am using the software renderer, i suspect that this is not
> > specific to my graphics card.
> >
> > i have a laptop with an identical software configuration that does not
> > suffer from this problem which uses an intel graphics card.
> >
> > i DONT GET THIS PROBLEM WITH THE CLOSED SOURCE NVIDIA DRIVERS,
> >
> >
> > on startup i get a dialog box with "critical error" in its title but
> > no text or buttons.
> >
> >
> > Debug [Main]: resize QSize(1024, 577)
> > Debug [Main]: Running Mixxx
> > Debug [Main]: ControllerManager::getControllerList
> > Warning [Main]: QGLShader: could not create shader
> > Warning [Main]: Vertex shad...

Read more...

RJ Skerry-Ryan (rryan) wrote :

Marking fixed -- thanks Daniel!

Changed in mixxx:
status: In Progress → Fix Committed
RJ Skerry-Ryan (rryan) on 2013-05-09
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers