[trunk] Finding crashes

[jorgk3]

Hi all,

I've started looking at some crashes in the Musescore trunk this week. I noticed that they can be a little difficult to find as Q_ASSERT and various abort() statements throughout the code stop the application (and on Windows also the debugger), so you don't get a stack trace after the crash has happened.

As good programming practise I suggest to funnel all application aborts through qFatal (which is also used by Q_ASSERT). Then we would be able to trap any abort in a message handler we can install.

Details can be found in:
http://musescore.org/en/handbook/finding-crashes
http://musescore.org/en/node/14748
http://musescore.org/en/node/14764

It would be a 10 minute exercise to visit all abort()'s in the system, remove them and change the preceding qDebug to a qFatal. This 10 minute investment will amortise itself in not time.

In the future, this central place to handle aborts can of course be used to collect information that will allow us to improve the product. Right now the proposed change will save the developers and perhaps even the testers a lot of time.

Opinions?

Jörg.

[Miwarre]

jorgk3 wrote

[...]As good programming practise I suggest to funnel all application aborts through qFatal (which is also used by Q_ASSERT). Then we would be able to trap any abort in a message handler we can install.[...]

I second this proposal:if locating problems is quicker, the stability of the code will improve quicker.

M.

[Werner Schweer]

Hi Jörg,

my opinion is that you seriously should consider a system for
developing/debugging which
is not as broken as the system you are using. Especially the need for
instrumenting
the app to get a stack trace looks very strange to me.

Werner

On 02/03/2012 04:29 PM, jorgk3 wrote:

> Hi all,
>
> I've started looking at some crashes in the Musescore trunk this week. I
> noticed that they can be a little difficult to find as Q_ASSERT and various
> abort() statements throughout the code stop the application (and on Windows
> also the debugger), so you don't get a stack trace after the crash has
> happened.
>
> As good programming practise I suggest to funnel all application aborts
> through qFatal (which is also used by Q_ASSERT). Then we would be able to
> trap any abort in a message handler we can install.
>
> Details can be found in:
> http://musescore.org/en/handbook/finding-crashes
> http://musescore.org/en/node/14748
> http://musescore.org/en/node/14764
>
> It would be a 10 minute exercise to visit all abort()'s in the system,
> remove them and change the preceding qDebug to a qFatal. This 10 minute
> investment will amortise itself in not time.
>
> In the future, this central place to handle aborts can of course be used to
> collect information that will allow us to improve the product. Right now the
> proposed change will save the developers and perhaps even the testers a lot
> of time.
>
> Opinions?
>
> Jörg.
>
> --
> View this message in context: http://musescore-developer.685061.n2.nabble.com/trunk-Finding-crashes-tp7251092p7251092.html
> Sent from the MuseScore Developer mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Mscore-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[jorgk3]

Hi Werner,

I don't understand what you are saying. What are you saying about a "broken system"?

It's a reasonably fresh install of Windows XP with a fresh install of Qt.

It's convenient to work in the Qt Creator debugger. The fact is that if the application uses abort(), the debugger stops and one doesn't get a stack trace or the chance to inspect anything.

So unless I want to swap to Linux or Mac, there is nothing I can change.

What we should change is to channel all the debug and terminations in the system through a central point, where we can then set a breakpoint. Since the Qt runtime uses Q_ASSERT (which calls qFatal and abort()), trapping the qFatal in a message handler (as described) is essential.

A simple statement
  Note* upnote = upNote();
can cause a crash via Q_ASSERT, if the list of notes is empty.

As I said, the suggested changes would establish the good practise not to exit the application in 60 different locations and improve the ability to debug it under Windows.

Jörg.

[jorgk3]

Have you read this?

https://bugreports.qt-project.org/browse/QTCREATORBUG-6203

If somewhere in the code a Q_ASSERT() evaluates false, the application is stopped with an info, where the Q_ASSERT() is and what expression evaluates false. If the application was run with a debugger, debugger is also stopped. If the developer wants to inspect a call stack, he must call qInstallMsgHandler() with a new MsgHandler, set a breakpoint in it and reproduce the bug. This is somewhat cumbersome.

[Miwarre]

Just an empirical note:

I have three MuseScore dev installations: one (trunk) under Ubuntu 11.10, one (trunk) under Win7 and one (branch) under Win XP; all use Qt Creator as IDE and debugger.

On all three, in the event of a program unexpected termination, sometime I get a stack trace, sometime I don't: I could not establish a pattern (I did not tried that much, to be honest: too many variables). So any help in locating the 'right' program point would be useful.

Thanks,

M.

[jorgk3]

My experience and research for Windows show:
1) Zero devide, referencing through a null pointer, etc. gives an operating system signal to the debugger which is processed. You get a stack trace.
2) Calling abort() directly from the application or from within Q_ASSERT stops the debugger with no stack trace.

Details here:
http://musescore.org/en/developers-handbook/finding-crashes

I suggest you try the patch and set a breakpoint in the message handler.
http://musescore.org/en/node/14748

Since the 60 odd calls to abort() we have in the trunk are all preceded (or so I hope, I didn't inspect them all) by a qDebug, you can also catch the following crash by putting a breakpoint into the message handler for qDebug.

Even if Mac or Linux should give you better debugging support:
1) a message handler is still useful for debugging purposes
2) not exiting an application in more than one location is good practise (which also helps debugging and enables us to collect crash information)

[jorgk3]

The patch has been applied and the message handler (mscoreMessageHandler) can be found just before main() in musescore.cpp.

Note that the code is conditionally compiled only under Windows:
#if defined(QT_DEBUG) && defined(Q_WS_WIN)

This may be a disadvantage for developers on other platforms. Developers on Mac and Linux who want to try it need to remove the && defined(Q_WS_WIN).

===

I still think we need to review the way we abort the application in approx. 60 locations. I am in favour of calling qFatal or using a macro as proposed in
http://musescore.org/en/node/14764

[Werner Schweer]

To make it clear: the added exit handler does not make any sense for
developers on linux
(and i believe on mac). Its only there to support an obviously broken
windows
environment. There is no disadvantage for non windows developers.

On 02/09/2012 03:23 PM, jorgk3 wrote:

> The patch has been applied and the message handler (mscoreMessageHandler) can
> be found just before main() in musescore.cpp.
>
> Note that the code is conditionally compiled only under Windows:
> #if defined(QT_DEBUG)&&  defined(Q_WS_WIN)
>
> This may be a disadvantage for developers on other platforms. Developers on
> Mac and Linux who want to try it need to remove the&&  defined(Q_WS_WIN).
>
> ===
>
> I still think we need to review the way we abort the application in approx.
> 60 locations. I am in favour of calling qFatal or using a macro as proposed
> in
> http://musescore.org/en/node/14764
>
> --
> View this message in context: http://musescore-developer.685061.n2.nabble.com/trunk-Finding-crashes-tp7251092p7269391.html
> Sent from the MuseScore Developer mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Mscore-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer