GUI closes without error message

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

GUI closes without error message

mso@asetek.com

I am experiencing that my GUI closes without warning or any reason. It happens both when running a script or running a function in the command window. It happens randomly and if I re-open the GUI and run the same function or scripts it normally functions.

The same happens for me on two different computers.

 

Any idea on what might be wrong?

 

I use Windows 10 and 5.2.0 version.

 


Asetek
MICHAEL HOLME SØRENSEN
Development Engineer, Motor design | Global R&D
Assensvej 2, 9220 Aalborg East, Denmark
Mobile +45 25 66 68 54 |  Office +45 96 45 30 60 |  Ext. 360 | www.asetek.com
Facebook | Asetek Twitter | Asetek Youtube | Asetek Asetek | Linkedin

The information contained in this email message may be privileged and is confidential information intended only for the use of the recipient named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, any use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone or email and destroy the original message from your electronic files.






Reply | Threaded
Open this post in threaded view
|

Re: GUI closes without error message

mmuetzel
Am 23. Juni 2020 um 14:12 Uhr schrieb "Michael Holme Sørensen":
> I am experiencing that my GUI closes without warning or any reason. It happens both when running a script or running a function in the command window. It happens randomly and if I re-open the GUI and run the same function or scripts it normally functions.
> The same happens for me on two different computers.

> Any idea on what might be wrong?

> I use Windows 10 and 5.2.0 version.
 
It's difficult to guess what might be happening without more information.

Which functions are you running when the Octave GUI closes unexpectedly?
Any open figures or variables in the variable editor?
Any loaded packages?
Does it also occur with the CLI?

Can you attach gdb to the PID of the running Octave process and try if it catches any exception? In case it does: What is the backtrace of the error?

Markus



Reply | Threaded
Open this post in threaded view
|

Re: GUI closes without error message

nrjank
Administrator
Can you attach gdb to the PID of the running Octave process and try if it catches any exception? In case it does: What is the backtrace of the error?

Do we have instructions for doing that on a Windows install without rebuilding? Is that possible? I believe there was recently another email chain about needing to build a Windows version that still had the debug symbols for gdb?


Reply | Threaded
Open this post in threaded view
|

Re: GUI closes without error message

mmuetzel
Am 23. Juni 2020 um 17:53 Uhr schrieb "Nicholas Jankowski":
> > Can you attach gdb to the PID of the running Octave process and try if it catches any exception? In case it does: What is the backtrace of the error?

> Do we have instructions for doing that on a Windows install without rebuilding? Is that possible? I believe there was recently another email chain about needing to build a Windows version that still had the debug symbols for gdb?

I was afraid that something like this would be what stayed from that other thread.
Let me try to be as clear as possible about this: It is *not* necessary to rebuild Octave to be able to attach gdb to it.
In fact, Octave for Windows already comes with a complete msys2 environment including a working gdb out of the box.

I never understood why the guy from that other thread insisted on re-compiling Octave for Windows. I tried to make that point repeatedly but it looks like it never came across.

The biggest difference is maybe that the backtrace references the mangled function names (without any source file line numbers). But such backtraces can give a good idea where a crash is occurring many times anyway.

HTH,
Markus



Reply | Threaded
Open this post in threaded view
|

Re: GUI closes without error message

nrjank
Administrator
On Tue, Jun 23, 2020 at 12:32 PM Markus Mützel <[hidden email]> wrote:
Am 23. Juni 2020 um 17:53 Uhr schrieb "Nicholas Jankowski":
> > Can you attach gdb to the PID of the running Octave process and try if it catches any exception? In case it does: What is the backtrace of the error?

> Do we have instructions for doing that on a Windows install without rebuilding? Is that possible? I believe there was recently another email chain about needing to build a Windows version that still had the debug symbols for gdb?

Let me try to be as clear as possible about this: It is *not* necessary to rebuild Octave to be able to attach gdb to it.


ok, if you had laid out the procedure before can you link to it? or maybe that would be worth a wiki page add. 


Reply | Threaded
Open this post in threaded view
|

Re: Re: GUI closes without error message

John W. Eaton
Administrator
In reply to this post by nrjank
On 6/23/20 11:53 AM, Nicholas Jankowski wrote:
>     Can you attach gdb to the PID of the running Octave process and try
>     if it catches any exception? In case it does: What is the backtrace
>     of the error?
>
>
> Do we have instructions for doing that on a Windows install without
> rebuilding? Is that possible? I believe there was recently another email
> chain about needing to build a Windows version that still had the debug
> symbols for gdb?

I have been able to use the following command at the Octave prompt on a
Windows system to start gdb in a separate command window and attach it
to the current Octave process:

   system (sprintf ("start gdb -p %d", getpid ()));

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Re: GUI closes without error message

Torsten Lilge
On Tue, 2020-06-23 at 13:03 -0400, John W. Eaton wrote:

> On 6/23/20 11:53 AM, Nicholas Jankowski wrote:
> >     Can you attach gdb to the PID of the running Octave process and
> > try
> >     if it catches any exception? In case it does: What is the
> > backtrace
> >     of the error?
> >
> >
> > Do we have instructions for doing that on a Windows install without
> > rebuilding? Is that possible? I believe there was recently another
> > email
> > chain about needing to build a Windows version that still had the
> > debug
> > symbols for gdb?
>
> I have been able to use the following command at the Octave prompt on
> a
> Windows system to start gdb in a separate command window and attach
> it
> to the current Octave process:
>
>    system (sprintf ("start gdb -p %d", getpid ()));
>
> jwe

John, this command links gdb to the worker thread, right? Is there a
possibility to get the gui's pid from within octave?

Torsten
 



Reply | Threaded
Open this post in threaded view
|

Re: Re: GUI closes without error message

nrjank
Administrator
John, this command links gdb to the worker thread, right? Is there a
possibility to get the gui's pid from within octave? 

in Windows, starting the GUI creates two processes 
- Console Window Host (conhost.exe)
- octave-gui.exe 

the getpid() command does return the pid of octave-gui.exe.


Reply | Threaded
Open this post in threaded view
|

Re: Re: GUI closes without error message

nrjank
Administrator
On Tue, Jun 23, 2020 at 2:59 PM Nicholas Jankowski <[hidden email]> wrote:
John, this command links gdb to the worker thread, right? Is there a
possibility to get the gui's pid from within octave? 

in Windows, starting the GUI creates two processes 
- Console Window Host (conhost.exe)
- octave-gui.exe 

the getpid() command does return the pid of octave-gui.exe.

running John's command, however, does lock the main octave program until you quit from adb, though, so i'm not sure if there's another way to call it that it will catch an exception that crashes octave.


Reply | Threaded
Open this post in threaded view
|

Re: Re: GUI closes without error message

mmuetzel
Am 23. Juni 2020 um 21:17 Uhr schrieb "Nicholas Jankowski":
> running John's command, however, does lock the main octave program until you quit from adb, though, so i'm not sure if there's another way to call it that it will catch an exception that crashes octave.

That is the expected behavior when gdb attaches to a process. At that point, you would e.g. be able to add breakpoints if you needed to.
When you are ready continue executing the process with the command "continue" (or just "c") at the gdb prompt.
After that the gdb prompt seems "unresponsive" because execution returned to Octave.

HTH,
Markus


Reply | Threaded
Open this post in threaded view
|

Re: Re: GUI closes without error message

nrjank
Administrator

On Tue, Jun 23, 2020 at 3:25 PM Markus Mützel <[hidden email]> wrote:
Am 23. Juni 2020 um 21:17 Uhr schrieb "Nicholas Jankowski":
> running John's command, however, does lock the main octave program until you quit from adb, though, so i'm not sure if there's another way to call it that it will catch an exception that crashes octave.

That is the expected behavior when gdb attaches to a process. At that point, you would e.g. be able to add breakpoints if you needed to.
When you are ready continue executing the process with the command "continue" (or just "c") at the gdb prompt.
After that the gdb prompt seems "unresponsive" because execution returned to Octave.


ok, thanks.  maybe this is something we could detail over on the wiki?  I know there's a spot for collecting hard-to-troubleshoot windows crash issues here:

not sure if there's a better place for this. but for general clueless windows users like me, something including 

- the command to start adb
 system (sprintf ("start gdb -p %d", getpid ())); 

- the way to get back to 'normal' octave operation
'continue'

- then run octave as normal to recreate the crash, and ....  what's next?  generate a report? it'll automatically generate one? do we need to run commands before 'continue' to tell it what/where to dump some output? 

- and what to send back to the help list to help developers troubleshoot? 

- if any of this falls under 'fails to start', can this be started from the CLI before launching Octave to capture the startup crash details?
 



Reply | Threaded
Open this post in threaded view
|

Re: GUI closes without error message

siko1056
On 6/24/20 5:20 AM, Nicholas Jankowski wrote:

>
> ok, thanks.  maybe this is something we could detail over on the wiki? 
> I know there's a spot for collecting hard-to-troubleshoot windows crash
> issues here:
> https://wiki.octave.org/FAQ#MS_Windows
>
> not sure if there's a better place for this. but for general clueless
> windows users like me, something including 
>
> - the command to start adb
>  system (sprintf ("start gdb -p %d", getpid ())); 
>
> - the way to get back to 'normal' octave operation
> 'continue'
>
> - then run octave as normal to recreate the crash, and ....  what's
> next?  generate a report? it'll automatically generate one? do we need
> to run commands before 'continue' to tell it what/where to dump some
> output? 
>
> - and what to send back to the help list to help developers troubleshoot? 
>
> - if any of this falls under 'fails to start', can this be started from
> the CLI before launching Octave to capture the startup crash details?
>  

The help thread was successfully hijacked :D

@Nicholas: Maybe you can overhaul that wiki page [1] and link from [2]
to it.  It almost contains all the information given here.

Kai

[1] https://wiki.octave.org/Debugging_Octave
[2] https://wiki.octave.org/FAQ#MS_Windows


Reply | Threaded
Open this post in threaded view
|

RE: Re: GUI closes without error message

mso@asetek.com
In reply to this post by nrjank

Thanks for all your inputs. I have started the gdb as proposed based on the small guideline from Nicholas. Please let me know how to pull out a report from this when I experience the failure next time.

 

Thanks, Michael

 



Michael Holme Sørensen
Development Engineer, Motor design | Global R&D

Asetek
Assensvej 2, 9220 Aalborg East, Denmark
www.asetek.com
Mobile +45 25 66 68 54
Office +45 96 45 30 60 Ext. 360



From: Nicholas Jankowski <[hidden email]>
Sent: 23. juni 2020 22:21
To: Markus Mützel <[hidden email]>
Cc: Nicholas Jankowski <[hidden email]>; Torsten Lilge <[hidden email]>; John W. Eaton <[hidden email]>; Michael Holme Sørensen <[hidden email]>; [hidden email]
Subject: Re: Re: GUI closes without error message

 

 

On Tue, Jun 23, 2020 at 3:25 PM Markus Mützel <[hidden email]> wrote:

Am 23. Juni 2020 um 21:17 Uhr schrieb "Nicholas Jankowski":
> running John's command, however, does lock the main octave program until you quit from adb, though, so i'm not sure if there's another way to call it that it will catch an exception that crashes octave.

That is the expected behavior when gdb attaches to a process. At that point, you would e.g. be able to add breakpoints if you needed to.
When you are ready continue executing the process with the command "continue" (or just "c") at the gdb prompt.
After that the gdb prompt seems "unresponsive" because execution returned to Octave.

 

ok, thanks.  maybe this is something we could detail over on the wiki?  I know there's a spot for collecting hard-to-troubleshoot windows crash issues here:

 

not sure if there's a better place for this. but for general clueless windows users like me, something including 

 

- the command to start adb

 system (sprintf ("start gdb -p %d", getpid ())); 

 

- the way to get back to 'normal' octave operation

'continue'

 

- then run octave as normal to recreate the crash, and ....  what's next?  generate a report? it'll automatically generate one? do we need to run commands before 'continue' to tell it what/where to dump some output? 

 

- and what to send back to the help list to help developers troubleshoot? 

 

- if any of this falls under 'fails to start', can this be started from the CLI before launching Octave to capture the startup crash details?

 

 



Caution: This email originated from outside Asetek. Do not click links, open attachments or forward unless you recognize the sender and know the content is safe.





Reply | Threaded
Open this post in threaded view
|

RE: Re: GUI closes without error message

mmuetzel
Am 24. Juni 2020 um 08:19 Uhr schrieb "Michael Holme Sørensen":
> Thanks for all your inputs. I have started the gdb as proposed based on the small guideline from Nicholas. Please let me know how to pull out a report from this when I experience the failure next time.

> Thanks, Michael


Please, use bottom or interleaved posting on this mailing list.

When the error occurs while gdb is attached to Octave and if gdb is able to catch the signal, change to the gdb prompt and enter "bt". That will display the backtrace of where the error occured.
Send the output in the gdb window to this mailing list.

HTH,
Markus



Reply | Threaded
Open this post in threaded view
|

Re: GUI closes without error message

John W. Eaton
Administrator
On 6/24/20 3:12 AM, Markus Mützel wrote:

> Am 24. Juni 2020 um 08:19 Uhr schrieb "Michael Holme Sørensen":
>> Thanks for all your inputs. I have started the gdb as proposed based on the small guideline from Nicholas. Please let me know how to pull out a report from this when I experience the failure next time.
>>  
>> Thanks, Michael
>>  
>
> Please, use bottom or interleaved posting on this mailing list.
>
> When the error occurs while gdb is attached to Octave and if gdb is able to catch the signal, change to the gdb prompt and enter "bt". That will display the backtrace of where the error occured.
> Send the output in the gdb window to this mailing list.

In addition to the "bt" (or "where") command that will show the location
in the current thread, it can also be useful to know what is happening
in all threads at the point of the crash.  To get that info, execute

   thread apply all bt

at the (gdb) prompt.

jwe