Debugging output

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging output

LachlanA
Greetings all,

I find it hard to debug crashes of GUI behaviour because  stderr  is redirected to the GUI, which disappears on the crash.  Does anyone else have the same problem?  If so, how do you overcome it?

If there is no simple work-around, I'd suggest that stderr still go to the console, even if it is also sent to the GUI.  Would that behaviour be acceptable?

Also, I find that I often want a stack trace after a crash.  Since crashes should be rare, and stack traces are small, I think there is a case for always trying to output a stack trace from the signal handler.  I know that the recommended approach is to use gdb, which seems fine for the CLI, but running "bt" in gdb doesn't give the stack trace of the GUI thread.  This behaviour could be disabled for the releases if you think the general public wouldn't like it, but I think it would be useful to have in the development branch.

Thoughts?

Lachlan
Reply | Threaded
Open this post in threaded view
|

Re: Debugging output

Daniel Sebald
On 01/30/2016 04:53 PM, LachlanA wrote:
> Greetings all,
>
> I find it hard to debug crashes of GUI behaviour because  stderr  is
> redirected to the GUI, which disappears on the crash.  Does anyone else have
> the same problem?  If so, how do you overcome it?

 From what I remember, the stderr/stdout/signal handling is a delicate
thing in the GUI/core setup.  There were several bug/patch reports along
the way, but I don't think an acceptable solution ever emerged.


> If there is no simple work-around, I'd suggest that stderr still go to the
> console, even if it is also sent to the GUI.  Would that behaviour be
> acceptable?

Try it, but it might have side effects like cntrl-C not working correct
or whatnot.  My guess is you won't find a quick fix, although an
in-depth fix might be possible.  But there are multiple platforms to
consider, so...


> Also, I find that I often want a stack trace after a crash.  Since crashes
> should be rare, and stack traces are small, I think there is a case for
> always trying to output a stack trace from the signal handler.  I know that
> the recommended approach is to use gdb, which seems fine for the CLI, but
> running "bt" in gdb doesn't give the stack trace of the GUI thread.  This
> behaviour could be disabled for the releases if you think the general public
> wouldn't like it, but I think it would be useful to have in the development
> branch.
>
> Thoughts?

Search around the Qt documentation for "qt debugging techniques", or
"qDebug", and such.  Maybe that will help.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Debugging output

LachlanA
Daniel Sebald wrote
 From what I remember, the stderr/stdout/signal handling is a delicate
thing in the GUI/core setup.  There were several bug/patch reports along
the way, but I don't think an acceptable solution ever emerged.

... it might have side effects like cntrl-C not working correct
or whatnot.  My guess is you won't find a quick fix, although an
in-depth fix might be possible.  But there are multiple platforms to
consider, so...

Search around the Qt documentation for "qt debugging techniques", or
"qDebug", and such.  Maybe that will help.
Thanks, Dan.  That is good background to know.  I'll put it low down on the to-do list :)

Regarding qDebug, that only works for printing in the Qt portion of the code itself.  If GUI behaviour causes a crash in Octave core code, then stderr/cerr is still useful, and Qt doesn't provide a stack trace, AFAICT.
Reply | Threaded
Open this post in threaded view
|

Re: Debugging output

Daniel Sebald
On 01/31/2016 06:57 PM, LachlanA wrote:

> Daniel Sebald wrote
>>    From what I remember, the stderr/stdout/signal handling is a delicate
>> thing in the GUI/core setup.  There were several bug/patch reports along
>> the way, but I don't think an acceptable solution ever emerged.
>>
>> ... it might have side effects like cntrl-C not working correct
>> or whatnot.  My guess is you won't find a quick fix, although an
>> in-depth fix might be possible.  But there are multiple platforms to
>> consider, so...
>>
>> Search around the Qt documentation for "qt debugging techniques", or
>> "qDebug", and such.  Maybe that will help.
>
> Thanks, Dan.  That is good background to know.  I'll put it low down on the
> to-do list :)
>
> Regarding qDebug, that only works for printing in the Qt portion of the code
> itself.  If GUI behaviour causes a crash in Octave core code, then
> stderr/cerr is still useful, and Qt doesn't provide a stack trace, AFAICT.

I agree, as I use stderr quite a bit by just placing fprintf() in
various places and watch what does or doesn't appear before the crash.
A Qt equivalent might be to call a one-line modal dialog box and simply
hit "OK" every time the text, then note where the crash occurs.  Clumsy,
but works.

If debugging something in the core of Octave, then octave-cli and
fprintf(stderr,) still works.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Debugging output

LachlanA
Daniel Sebald wrote
A Qt equivalent might be to call a one-line modal dialog box and simply
hit "OK" every time the text, then note where the crash occurs.  Clumsy,
but works.

If debugging something in the core of Octave, then octave-cli and
fprintf(stderr,) still works.
The modal dialog is a great idea.  I hadn't thought of that.

Using Octave-cli is fine for debugging purely core issues.  As I said, the problem is if doing ABC in the GUI causes crash XYZ in the core.  Perhaps it is a corner case...

Thanks again for the tips,
Lachlan
Reply | Threaded
Open this post in threaded view
|

Re: Debugging output

Daniel Sebald
On 01/31/2016 07:31 PM, LachlanA wrote:

> Daniel Sebald wrote
>> A Qt equivalent might be to call a one-line modal dialog box and simply
>> hit "OK" every time the text, then note where the crash occurs.  Clumsy,
>> but works.
>>
>> If debugging something in the core of Octave, then octave-cli and
>> fprintf(stderr,) still works.
>
> The modal dialog is a great idea.  I hadn't thought of that.
>
> Using Octave-cli is fine for debugging purely core issues.  As I said, the
> problem is if doing ABC in the GUI causes crash XYZ in the core.  Perhaps it
> is a corner case...

My view is that it should be, by design.  I've always felt that the GUI
should be able to set/retrieve anything via some existing command.  The
only place that might not apply is graphics engine efficiency.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Debugging output

Richard Crozier
In reply to this post by LachlanA
On 30/01/16 22:53, LachlanA wrote:
> Greetings all,
>
> I find it hard to debug crashes of GUI behaviour because  stderr  is
> redirected to the GUI, which disappears on the crash.  Does anyone else have
> the same problem?  If so, how do you overcome it?
>

<snip>

>
> Thoughts?
>
> Lachlan
>
>
>

would just using 'diary on' help with this kind of debugging? This
records everything in a file as though it appears in the terminal.

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.