Octave Installer for Windows with Debug Option

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

Octave Installer for Windows with Debug Option

ellocco
Hi,

currently I try to debug octave-pythonic on a windows machine, see: 
and to do the job I am looking for an Octave Installer build with the debug-option.
The description to build the installer: 
does not fit to what you downloading from the repository.

I guess I am not experienced enough to build the installer without a proper description.
Can someone provide an appropriate installer or a detailed step-by-step description
to do the job?

Regards,

Stefan

--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001


Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
Am 06. Juni 2020 um 00:43 Uhr schrieb "Stefan Pofahl":

> Hi,

> currently I try to debug octave-pythonic on a windows machine, see: 
> https://gitlab.com/mtmiller/octave-pythonic/-/issues/81
> and to do the job I am looking for an Octave Installer build with the debug-option.
> The description to build the installer: 
> http://wiki.octave.org/Windows_Installer
> does not fit to what you downloading from the repository.

> I guess I am not experienced enough to build the installer without a proper description.
> Can someone provide an appropriate installer or a detailed step-by-step description
> to do the job?

> Regards,

> Stefan
>

Hi Stefan,

Could you describe which problems you are facing?
The instruction on the wiki page you linked to do still apply afaict. But if you could point out what is missing, it can always be improved.

Some general notes: If you want a cross-build for Windows without stripping the debug symbol, it is not possible to create an installer (because of maximum size). I'd suggest to build a 7z tarball.

To cross-compile the latest release from a Linux box with debug symbols, I'd probably try these steps:
hg clone https://hg.octave.org/mxe-octave/ mxe-octave
cd mxe-octave
./bootstrap
./configure --enable-devel-tools --enable-windows-64 --enable-octave=release --enable-binary-packages --with-pkg-dir=../mxe-octave-pkg --with-ccache --disable-system-opengl --enable-qt5 --disable-strip-dist-files
make all 7z-dist JOBS=4


Note that cross-compiling the complete package will probably take several hours on decent hardware. And you'd need about 20 GiB free disc space (plus additional space for the compiler cache if you want to use ccache - which I'd highly recommend to speed up subsequent builds).

HTH,
Markus


Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
Am 06. Juni 2020 um 09:53 Uhr schrieb "Markus Mützel":

> Am 06. Juni 2020 um 00:43 Uhr schrieb "Stefan Pofahl":
> > Hi,
> > 
> > currently I try to debug octave-pythonic on a windows machine, see: 
> > https://gitlab.com/mtmiller/octave-pythonic/-/issues/81
> > and to do the job I am looking for an Octave Installer build with the debug-option.
> > The description to build the installer: 
> > http://wiki.octave.org/Windows_Installer
> > does not fit to what you downloading from the repository.
> > 
> > I guess I am not experienced enough to build the installer without a proper description.
> > Can someone provide an appropriate installer or a detailed step-by-step description
> > to do the job?
> > 
> > Regards,
> > 
> > Stefan
> >
>
> Hi Stefan,
>
> Could you describe which problems you are facing?
> The instruction on the wiki page you linked to do still apply afaict. But if you could point out what is missing, it can always be improved.
>
> Some general notes: If you want a cross-build for Windows without stripping the debug symbol, it is not possible to create an installer (because of maximum size). I'd suggest to build a 7z tarball.
>
> To cross-compile the latest release from a Linux box with debug symbols, I'd probably try these steps:
> hg clone https://hg.octave.org/mxe-octave/ mxe-octave
> cd mxe-octave
> ./bootstrap
> ./configure --enable-devel-tools --enable-windows-64 --enable-octave=release --enable-binary-packages --with-pkg-dir=../mxe-octave-pkg --with-ccache --disable-system-opengl --enable-qt5 --disable-strip-dist-files
> make all 7z-dist JOBS=4
>
>
> Note that cross-compiling the complete package will probably take several hours on decent hardware. And you'd need about 20 GiB free disc space (plus additional space for the compiler cache if you want to use ccache - which I'd highly recommend to speed up subsequent builds).
>
> HTH,
> Markus
>

I tried to read through the gitlab pull request you linked to. It is very convoluted and hard to understand what you really want.
So I kind of have to guess what you really need. Generally, please try to state what your real issue is - as opposed to asking for assistance for something that you *suspect* to be a step towards a solution. See also: https://en.wikipedia.org/wiki/XY_problem

Guessing that you try to debug an error with the GUI on Windows, you don't really need to cross-compile yourself.
Maybe try this first:
Start the GUI on Windows.
Open the Task Manager and find the PID of the running Octave instance.
Browse to the folder where Octave is installed and open an msys shell with "cmdshell.bat".
Run "gdb" in the shell.
Attach to the Octave process with the following command (where 12345 is the PID of the Octave process):
(gdb) attach 12345
(gdb) continue

Run the commands that cause the error in Octave.
When the crash occurred, go back to gdb and do whatever you need to get the necessary information. E.g. for a backtrace, execute "bt".

You'd probably need to make yourself somewhat familiar with gdb.

HTH
Markus




Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
In reply to this post by ellocco
Forgot to CC the mailing list. So here the same message again. Sorry for that:

Am 06. Juni 2020 um 22:39 Uhr schrieb "Stefan Pofahl"
> Hi Markus,

> thanks a lot for your response!. As you can read in my post:
> https://gitlab.com/mtmiller/octave-pythonic/-/issues/81

> I have managed to run "gdb".

That is a first step.

> The issue is, gdb tells me, octave-gui is not built with the debug option.

Those messages don't say that you won't be able to get any information at all. It just means that e.g. backtraces won't cite the source code and line for functions in Octave core. They should still contain the function names (even if they might be mangled).

Have you been able to reproduce the crash that you want to inspect while gdb was attached to Octave?
What did the backtrace look like?

> Therefore, I agree, it might be enough to have a DGB-version of octave-gui.exe.

> Could you help me with that?

I don't know what you mean by that. But I have a feeling that you are jumping ahead again.
Have you read the Wikipedia article? ( https://en.wikipedia.org/wiki/XY_problem - also available in other languages.)
We don't know yet if the crash occurs in core Octave or in some .oct file or in a third party library. So at the moment, there is no way to tell if it would make sense for you to recompile Octave without stripping symbols...

HTH,
Markus

 
 



Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco
Hi,

thanks for your question.
The crashes are reproducible, they occur only on Windows, octave-gui.exe crashes most of the time during the command: Py_Initialize ().
There are two options: 
* There is a bug in "octave-gui" that is effective only inside the windows variant
* There is a chance to improve octave-pythonic

After gdb told me, octave-gui is not built with the debug option, I thought it does not make sense with further investigations without a 
debug-version of the octave-gui.

My hope is that someone in the mailing list can help me to get access to a debug-version of an octave-gui.

Is it possible to cross-compile only the "octave-gui.exe"?

Regards,

Stefan


Am So., 7. Juni 2020 um 10:05 Uhr schrieb Markus Mützel <[hidden email]>:
Forgot to CC the mailing list. So here the same message again. Sorry for that:

Am 06. Juni 2020 um 22:39 Uhr schrieb "Stefan Pofahl"
> Hi Markus,

> thanks a lot for your response!. As you can read in my post:
> https://gitlab.com/mtmiller/octave-pythonic/-/issues/81

> I have managed to run "gdb".

That is a first step.

> The issue is, gdb tells me, octave-gui is not built with the debug option.

Those messages don't say that you won't be able to get any information at all. It just means that e.g. backtraces won't cite the source code and line for functions in Octave core. They should still contain the function names (even if they might be mangled).

Have you been able to reproduce the crash that you want to inspect while gdb was attached to Octave?
What did the backtrace look like?

> Therefore, I agree, it might be enough to have a DGB-version of octave-gui.exe.

> Could you help me with that?

I don't know what you mean by that. But I have a feeling that you are jumping ahead again.
Have you read the Wikipedia article? ( https://en.wikipedia.org/wiki/XY_problem - also available in other languages.)
We don't know yet if the crash occurs in core Octave or in some .oct file or in a third party library. So at the moment, there is no way to tell if it would make sense for you to recompile Octave without stripping symbols...

HTH,
Markus

 
 



--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001


Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
Am 08. Juni 2020 um 00:15 Uhr schrieb "Stefan Pofahl":

> Hi,

> thanks for your question.
> The crashes are reproducible, they occur only on Windows, octave-gui.exe crashes most of the time during the command: Py_Initialize ().
> There are two options: 
> * There is a bug in "octave-gui" that is effective only inside the windows variant
> * There is a chance to improve octave-pythonic

> After gdb told me, octave-gui is not built with the debug option, I thought it does not make sense with further investigations without a 
> debug-version of the octave-gui.

> My hope is that someone in the mailing list can help me to get access to a debug-version of an octave-gui.

We are turning in circles. I doubt anyone on this list will be able to help you if you don't do your part.
Here again(!) as clearly as I can possibly manage:
- You wrote that you already know how to attach gdb to a running Octave process on Windows. Do that. Ignore the message about missing debugging symbols!
- Try to reproduce the crash while gdb is attached to Octave.
- Send the backtrace of the crash to this list.

> Is it possible to cross-compile only the "octave-gui.exe"?
>  

We'll come to that once we know that this would help.

Markus
  

And here the same in German in case my English isn't good enough to explain what you need to do:

Bitte, bitte(!) ließ die Emails durch, die du bekommst. Wenn dir irgendjemand helfen soll, musst du auch deinen Teil beitragen und Informationen liefern, nach denen du gefragt wirst!
So deutlich wie möglich hier nochmal die Schritte, die du befolgen solltest, damit wir herausfinden können, welche nächsten Schritte nötig sind:
- Du weißt schon, wie man sich mit gdb an einen laufenden Octave-Prozess anbindet. Tu das bitte. Beachte die Nachricht über die fehlenden Debugging-Symbole einfach nicht!
- Versuche, den Absturz zu verursachen, während gdb an den Octave-Prozess angebunden ist.
- Zeige uns hier auf der Liste den backtrace vom Absturz.

Erst danach können wir entscheiden, ob es überhaupt nötig ist, dass du Octave neu kompilieren musst. (Wie das geht, habe ich dir übrigens auch schon längst beschrieben.)

Markus


Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco
In reply to this post by mmuetzel
Hi,

here the status on the two objectives: a.) Debug via gdb b.) compile an octave-gui.exe including debug symbols

a)
I am working on it.
* I added 4 breakpoints
* Interrupted the gdb-terminal: c, ENTER
* Gave a command in octave-gui.exe
Strange thing there was no gdb.txt on the entire main drive c:\

b)
unfortunately the build crashed.
I used exactly the same commands Markus had proposed.
The problem seems to be that "CMAKE_MAKE_PROGRAM is not set."
Where should this be done?

--------------------------------------------------------------------------------------------------------------------
Failed to build package lapack!
------------------------------------------------------------
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
make[2]: *** [/home/spofahl/hg/mxe-octave/Makefile:940: build-only-lapack] Fehler 1
make[2]: Verzeichnis „/home/spofahl/hg/mxe-octave“ wird verlassen
real    0m2.232s
user    0m1.986s
sys     0m0.437s
----------------------------------------------------------------------------------------------------------------------

Regards,

Stefan


Regards,

Stefan


Am Sa., 6. Juni 2020 um 09:53 Uhr schrieb Markus Mützel <[hidden email]>:
Am 06. Juni 2020 um 00:43 Uhr schrieb "Stefan Pofahl":
> Hi,

> currently I try to debug octave-pythonic on a windows machine, see: 
> https://gitlab.com/mtmiller/octave-pythonic/-/issues/81
> and to do the job I am looking for an Octave Installer build with the debug-option.
> The description to build the installer: 
> http://wiki.octave.org/Windows_Installer
> does not fit to what you downloading from the repository.

> I guess I am not experienced enough to build the installer without a proper description.
> Can someone provide an appropriate installer or a detailed step-by-step description
> to do the job?

> Regards,

> Stefan
>

Hi Stefan,

Could you describe which problems you are facing?
The instruction on the wiki page you linked to do still apply afaict. But if you could point out what is missing, it can always be improved.

Some general notes: If you want a cross-build for Windows without stripping the debug symbol, it is not possible to create an installer (because of maximum size). I'd suggest to build a 7z tarball.

To cross-compile the latest release from a Linux box with debug symbols, I'd probably try these steps:
hg clone https://hg.octave.org/mxe-octave/ mxe-octave
cd mxe-octave
./bootstrap
./configure --enable-devel-tools --enable-windows-64 --enable-octave=release --enable-binary-packages --with-pkg-dir=../mxe-octave-pkg --with-ccache --disable-system-opengl --enable-qt5 --disable-strip-dist-files
make all 7z-dist JOBS=4


Note that cross-compiling the complete package will probably take several hours on decent hardware. And you'd need about 20 GiB free disc space (plus additional space for the compiler cache if you want to use ccache - which I'd highly recommend to speed up subsequent builds).

HTH,
Markus


--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001


Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
Am 09. Juni 2020 um 08:19 Uhr schrieb "Stefan Pofahl":

> Hi,

> here the status on the two objectives: a.) Debug via gdb b.) compile an octave-gui.exe including debug symbols

> a)
> I am working on it.
> * I added 4 breakpoints
> * Interrupted the gdb-terminal: c, ENTER
> * Gave a command in octave-gui.exe
> Strange thing there was no gdb.txt on the entire main drive c:\
>

Where did you set the breakpoints? Do you already know where the crashes occur? Please, try to provide as much necessary details as possible.
Anyway, it shouldn't be necessary to set breakpoints to get the backtrace from a crash.
Here what I think you should do in as much detail as I can possibly manage:
- Start Octave on Windows.
- When it has started, open the "Task Manager" and change to the "Details" tab.
- Look for "octave-gui.exe" in the "Name" column and take note of the corresponding number in the "PID" column.
- Browse to the folder where Octave is installed and execute "cmdshell.bat" to open a shell.
- In that shell, run "gdb"
- At the gdb prompt, enter "attach 12345" (where "12345" is the PID you noted above).
- At that point, the Octave GUI should be irresponsive. If you can still interact with the GUI, you attached to the wrong PID. In this case, quit gdb, close Octave and start from above.
- If you attached to the correct PID, enter "c" at the gdb prompt. The Octave GUI should be responsive again.
- Leave the shell with running gdb in the background. Execute the commands that cause the crash in Octave.
- As soon as the crash happened, change back to the shell with running gdb and enter "bt".
- Copy the backtrace displayed by gdb to a text file and save it.
- Send an email with the saved backtrace to this mailing list.
  

> b)
> unfortunately the build crashed.
> I used exactly the same commands Markus had proposed.
> The problem seems to be that "CMAKE_MAKE_PROGRAM is not set."
> Where should this be done?
>  
> --------------------------------------------------------------------------------------------------------------------
> Failed to build package lapack!
> ------------------------------------------------------------
> CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
> CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> make[2]: *** [/home/spofahl/hg/mxe-octave/Makefile:940: build-only-lapack] Fehler 1
> make[2]: Verzeichnis „/home/spofahl/hg/mxe-octave“ wird verlassen
> real    0m2.232s
> user    0m1.986s
> sys     0m0.437s
> ----------------------------------------------------------------------------------------------------------------------
>  
> Regards,
>  
> Stefan

Maybe, we should first focus on one problem and come back to the building issues later.

Regards,
Markus

PS: It is customary to use bottom posting or interleaved posting on this mailing list. It is courteous to adapt to that convention:
https://en.wikipedia.org/wiki/Posting_style#Placement_of_replies



Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco
Hi Markus,

thanks for the hint to move first to the directory where "octave-gui.exe" is located before starting
dbg.
I followed exactly your procedure.
And I followed an automated procedure.
Both give the same result.
Here my automated procedure to start gdb.exe
------------------------------------------------------------------------------------
DIR_octave_gui = 'C:\Octave\Octave-5.2.0\mingw64\bin';
if exist(DIR_octave_gui, 'dir')
    cd(DIR_octave_gui);
    pwd
end
if ispc
    % windows:
    % cmd.exe /c start "" "C:\Octave\Octave-5.2.0\mingw64\bin\gdb.exe" -p petpid
    s_cmd = sprintf( "cmd.exe /c start \"gdb\" \"C:\\Octave\\Octave-5.2.0\\mingw64\\bin\\gdb.exe\" -p %d", getpid() );
    system(s_cmd);
else
    % unix/linux:
    system(sprintf("gnome-terminal --command 'gdb -p %d'", getpid()), "async");
end
------------------------------------------------------------------------------------

I know exactly where it crashes, it is a function provided by python: Py_Initialize();
To provoke the crash I gave the command:
octave> pycall("sysconfig.get_python_version");

This command is nested inside "pyversion.m".

And this causes troubles only in the octave-gui.exe on Ubuntu and inside octave-cli everything
works fine. And it does not always crash, it crashes at least in 90% of the time.

Attached the screen output from gdb.exe.

Regards,

Stefan


Am Di., 9. Juni 2020 um 09:02 Uhr schrieb Markus Mützel <[hidden email]>:
Am 09. Juni 2020 um 08:19 Uhr schrieb "Stefan Pofahl":
> Hi,

> here the status on the two objectives: a.) Debug via gdb b.) compile an octave-gui.exe including debug symbols

> a)
> I am working on it.
> * I added 4 breakpoints
> * Interrupted the gdb-terminal: c, ENTER
> * Gave a command in octave-gui.exe
> Strange thing there was no gdb.txt on the entire main drive c:\
>

Where did you set the breakpoints? Do you already know where the crashes occur? Please, try to provide as much necessary details as possible.
Anyway, it shouldn't be necessary to set breakpoints to get the backtrace from a crash.
Here what I think you should do in as much detail as I can possibly manage:
- Start Octave on Windows.
- When it has started, open the "Task Manager" and change to the "Details" tab.
- Look for "octave-gui.exe" in the "Name" column and take note of the corresponding number in the "PID" column.
- Browse to the folder where Octave is installed and execute "cmdshell.bat" to open a shell.
- In that shell, run "gdb"
- At the gdb prompt, enter "attach 12345" (where "12345" is the PID you noted above).
- At that point, the Octave GUI should be irresponsive. If you can still interact with the GUI, you attached to the wrong PID. In this case, quit gdb, close Octave and start from above.
- If you attached to the correct PID, enter "c" at the gdb prompt. The Octave GUI should be responsive again.
- Leave the shell with running gdb in the background. Execute the commands that cause the crash in Octave.
- As soon as the crash happened, change back to the shell with running gdb and enter "bt".
- Copy the backtrace displayed by gdb to a text file and save it.
- Send an email with the saved backtrace to this mailing list.
  
> b)
> unfortunately the build crashed.
> I used exactly the same commands Markus had proposed.
> The problem seems to be that "CMAKE_MAKE_PROGRAM is not set."
> Where should this be done?
>  
> --------------------------------------------------------------------------------------------------------------------
> Failed to build package lapack!
> ------------------------------------------------------------
> CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
> CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> make[2]: *** [/home/spofahl/hg/mxe-octave/Makefile:940: build-only-lapack] Fehler 1
> make[2]: Verzeichnis „/home/spofahl/hg/mxe-octave“ wird verlassen
> real    0m2.232s
> user    0m1.986s
> sys     0m0.437s
> ----------------------------------------------------------------------------------------------------------------------
>  
> Regards,
>  
> Stefan


Maybe, we should first focus on one problem and come back to the building issues later.

Regards,
Markus

PS: It is customary to use bottom posting or interleaved posting on this mailing list. It is courteous to adapt to that convention:
https://en.wikipedia.org/wiki/Posting_style#Placement_of_replies



--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001



dbg_output.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
Please, use bottom or interleaved posting when writing to this mailing list.

Am 09. Juni 2020 um 10:10 Uhr schrieb "Stefan Pofahl":

> Hi Markus,
>  
> thanks for the hint to move first to the directory where "octave-gui.exe" is located before starting
> dbg.
> I followed exactly your procedure.
> And I followed an automated procedure.
> Both give the same result.
> Here my automated procedure to start gdb.exe
> ------------------------------------------------------------------------------------
> DIR_octave_gui = 'C:\Octave\Octave-5.2.0\mingw64\bin';
> if exist(DIR_octave_gui, 'dir')
>     cd(DIR_octave_gui);
>     pwd
> end
> if ispc
>     % windows:
>     % cmd.exe /c start "" "C:\Octave\Octave-5.2.0\mingw64\bin\gdb.exe" -p petpid
>     s_cmd = sprintf( "cmd.exe /c start \"gdb\" \"C:\\Octave\\Octave-5.2.0\\mingw64\\bin\\gdb.exe\" -p %d", getpid() );
>     system(s_cmd);
> else
>     % unix/linux:
>     system(sprintf("gnome-terminal --command 'gdb -p %d'", getpid()), "async");
> end
> ------------------------------------------------------------------------------------
>

Don't use "cmd.exe" but the "cmdshell.bat" in the directory where Octave is installed (*not* the directory where "octave-gui.exe" is!).
It's possible, the environment for gdb isn't set up correctly if you use "cmd.exe".
 
> I know exactly where it crashes, it is a function provided by python: Py_Initialize();
> To provoke the crash I gave the command:
> octave> pycall("sysconfig.get_python_version");

> This command is nested inside "pyversion.m".

> And this causes troubles only in the octave-gui.exe on Ubuntu and inside octave-cli everything
> works fine. And it does not always crash, it crashes at least in 90% of the time. 

If the problem only occurs on Ubuntu, why the trouble to debug on Windows?

> Attached the screen output from gdb.exe.


If you don't get a backtrace, Octave with symbols would not be any more helpful.

Markus
  



Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco
Ok Markus,

sorry for my mistake, I thought "cmdshell.bat" is more or less the same as "cmd.exe",
I was not aware of this batch-file.
Here is the new output:
-------------------------------------------------------------------------------------------------------
Reading symbols from C:\Octave\OCTAVE~1.0\mingw64\bin\octave-gui.exe...
(No debugging symbols found in C:\Octave\OCTAVE~1.0\mingw64\bin\octave-gui.exe)
(gdb) c
Continuing.
[Thread 14828.0x2920 exited with code 0]
[Thread 14828.0xc2c exited with code 0]

Thread 24 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 14828.0x3c1c]
0x00007ffe236015f9 in ucrtbase!_wcreat () from C:\WINDOWS\System32\ucrtbase.dll
(gdb) tb
Temporary breakpoint 1 at 0x7ffe236015f9
(gdb)
-------------------------------------------------------------------------------------------------------------

You wrote:
> If the problem only occurs on Ubuntu, why the trouble to debug on Windows?

It is the opposit, it crashes only in "octave-gui.exe"


Regards,

Stefan

Am Di., 9. Juni 2020 um 10:45 Uhr schrieb Markus Mützel <[hidden email]>:
Please, use bottom or interleaved posting when writing to this mailing list.

Am 09. Juni 2020 um 10:10 Uhr schrieb "Stefan Pofahl":
> Hi Markus,
>  
> thanks for the hint to move first to the directory where "octave-gui.exe" is located before starting
> dbg.
> I followed exactly your procedure.
> And I followed an automated procedure.
> Both give the same result.
> Here my automated procedure to start gdb.exe
> ------------------------------------------------------------------------------------
> DIR_octave_gui = 'C:\Octave\Octave-5.2.0\mingw64\bin';
> if exist(DIR_octave_gui, 'dir')
>     cd(DIR_octave_gui);
>     pwd
> end
> if ispc
>     % windows:
>     % cmd.exe /c start "" "C:\Octave\Octave-5.2.0\mingw64\bin\gdb.exe" -p petpid
>     s_cmd = sprintf( "cmd.exe /c start \"gdb\" \"C:\\Octave\\Octave-5.2.0\\mingw64\\bin\\gdb.exe\" -p %d", getpid() );
>     system(s_cmd);
> else
>     % unix/linux:
>     system(sprintf("gnome-terminal --command 'gdb -p %d'", getpid()), "async");
> end
> ------------------------------------------------------------------------------------
>

Don't use "cmd.exe" but the "cmdshell.bat" in the directory where Octave is installed (*not* the directory where "octave-gui.exe" is!).
It's possible, the environment for gdb isn't set up correctly if you use "cmd.exe".
 
> I know exactly where it crashes, it is a function provided by python: Py_Initialize();
> To provoke the crash I gave the command:
> octave> pycall("sysconfig.get_python_version");

> This command is nested inside "pyversion.m".

> And this causes troubles only in the octave-gui.exe on Ubuntu and inside octave-cli everything
> works fine. And it does not always crash, it crashes at least in 90% of the time. 

If the problem only occurs on Ubuntu, why the trouble to debug on Windows?

> Attached the screen output from gdb.exe.


If you don't get a backtrace, Octave with symbols would not be any more helpful.

Markus
  



--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001


Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco
Something more, after I hit two times more: "c" and than "tb" again. (see attached txt)


Am Di., 9. Juni 2020 um 11:23 Uhr schrieb Stefan Pofahl <[hidden email]>:
Ok Markus,

sorry for my mistake, I thought "cmdshell.bat" is more or less the same as "cmd.exe",
I was not aware of this batch-file.
Here is the new output:
-------------------------------------------------------------------------------------------------------
Reading symbols from C:\Octave\OCTAVE~1.0\mingw64\bin\octave-gui.exe...
(No debugging symbols found in C:\Octave\OCTAVE~1.0\mingw64\bin\octave-gui.exe)
(gdb) c
Continuing.
[Thread 14828.0x2920 exited with code 0]
[Thread 14828.0xc2c exited with code 0]

Thread 24 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 14828.0x3c1c]
0x00007ffe236015f9 in ucrtbase!_wcreat () from C:\WINDOWS\System32\ucrtbase.dll
(gdb) tb
Temporary breakpoint 1 at 0x7ffe236015f9
(gdb)
-------------------------------------------------------------------------------------------------------------

You wrote:
> If the problem only occurs on Ubuntu, why the trouble to debug on Windows?

It is the opposit, it crashes only in "octave-gui.exe"


Regards,

Stefan

Am Di., 9. Juni 2020 um 10:45 Uhr schrieb Markus Mützel <[hidden email]>:
Please, use bottom or interleaved posting when writing to this mailing list.

Am 09. Juni 2020 um 10:10 Uhr schrieb "Stefan Pofahl":
> Hi Markus,
>  
> thanks for the hint to move first to the directory where "octave-gui.exe" is located before starting
> dbg.
> I followed exactly your procedure.
> And I followed an automated procedure.
> Both give the same result.
> Here my automated procedure to start gdb.exe
> ------------------------------------------------------------------------------------
> DIR_octave_gui = 'C:\Octave\Octave-5.2.0\mingw64\bin';
> if exist(DIR_octave_gui, 'dir')
>     cd(DIR_octave_gui);
>     pwd
> end
> if ispc
>     % windows:
>     % cmd.exe /c start "" "C:\Octave\Octave-5.2.0\mingw64\bin\gdb.exe" -p petpid
>     s_cmd = sprintf( "cmd.exe /c start \"gdb\" \"C:\\Octave\\Octave-5.2.0\\mingw64\\bin\\gdb.exe\" -p %d", getpid() );
>     system(s_cmd);
> else
>     % unix/linux:
>     system(sprintf("gnome-terminal --command 'gdb -p %d'", getpid()), "async");
> end
> ------------------------------------------------------------------------------------
>

Don't use "cmd.exe" but the "cmdshell.bat" in the directory where Octave is installed (*not* the directory where "octave-gui.exe" is!).
It's possible, the environment for gdb isn't set up correctly if you use "cmd.exe".
 
> I know exactly where it crashes, it is a function provided by python: Py_Initialize();
> To provoke the crash I gave the command:
> octave> pycall("sysconfig.get_python_version");

> This command is nested inside "pyversion.m".

> And this causes troubles only in the octave-gui.exe on Ubuntu and inside octave-cli everything
> works fine. And it does not always crash, it crashes at least in 90% of the time. 

If the problem only occurs on Ubuntu, why the trouble to debug on Windows?

> Attached the screen output from gdb.exe.


If you don't get a backtrace, Octave with symbols would not be any more helpful.

Markus
  



--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001


--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001



dbg_output_in_cmdshell.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
In reply to this post by ellocco
Again: Please use bottom or interleaved posting when writing to this mailing list!

Am 09. Juni 2020 um 11:23 Uhr schrieb "Stefan Pofahl":

> Ok Markus,

> sorry for my mistake, I thought "cmdshell.bat" is more or less the same as "cmd.exe",
> I was not aware of this batch-file.
> Here is the new output:
> -------------------------------------------------------------------------------------------------------
> Reading symbols from C:\Octave\OCTAVE~1.0\mingw64\bin\octave-gui.exe...
> (No debugging symbols found in C:\Octave\OCTAVE~1.0\mingw64\bin\octave-gui.exe)
> (gdb) c
> Continuing.
> [Thread 14828.0x2920 exited with code 0]
> [Thread 14828.0xc2c exited with code 0]
>
> Thread 24 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 14828.0x3c1c]
> 0x00007ffe236015f9 in ucrtbase!_wcreat () from C:\WINDOWS\System32\ucrtbase.dll
> (gdb) tb
> Temporary breakpoint 1 at 0x7ffe236015f9
> (gdb)
> -------------------------------------------------------------------------------------------------------------
>

Well, this is tedious...
Please, do that again and request the backtrace with "bt" (not "tb"!)...
 
> You wrote:
> > If the problem only occurs on Ubuntu, why the trouble to debug on Windows?
>  
> It is the opposit, it crashes only in "octave-gui.exe"

This is not what you wrote in your previous message...

Markus




Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco


Am Di., 9. Juni 2020 um 11:32 Uhr schrieb Markus Mützel <[hidden email]>:
Again: Please use bottom or interleaved posting when writing to this mailing list!



Well, this is tedious...
Please, do that again and request the backtrace with "bt" (not "tb"!)...
 
Sorry for the Typo ... See the attached tb-output ...

 

Markus




--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001



dbg_output_in_cmdshell.txt (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

mmuetzel
Am 09. Juni 2020 um 12:17 Uhr schrieb "Stefan Pofahl":
> Sorry for the Typo ... See the attached tb-output ...

I was gasping again. But other than what you wrote in the mail body, you managed to enter the two letters in the correct order in gdb. Congratulations!

The crash occurs in the Visual C++ runtime libraries.

How did you install Python?

Maybe also try re-installing or repairing the Visual C++ runtime libraries. See e.g. here
https://support.microsoft.com/de-de/help/2977003/the-latest-supported-visual-c-downloads

Markus




Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco
Hi,

I have reinstalled c++-libraries and I have installed the new Python-version v3.8.3:

@Markus:
Thanks for the advice and the link to download the c++-libraries!

Unfortunately, it has not cured the problem.

Attached the new backtrace ("bt").

Regards,

Stefan

Am Di., 9. Juni 2020 um 12:34 Uhr schrieb Markus Mützel <[hidden email]>:
Am 09. Juni 2020 um 12:17 Uhr schrieb "Stefan Pofahl":
> Sorry for the Typo ... See the attached tb-output ...

I was gasping again. But other than what you wrote in the mail body, you managed to enter the two letters in the correct order in gdb. Congratulations!

The crash occurs in the Visual C++ runtime libraries.

How did you install Python?

Maybe also try re-installing or repairing the Visual C++ runtime libraries. See e.g. here
https://support.microsoft.com/de-de/help/2977003/the-latest-supported-visual-c-downloads

Markus




--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001



dbg_output_in_cmdshell_after_c++_reinstalled.txt (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Octave Installer for Windows with Debug Option

ellocco
Hi,

I have managed to compile a gdb-compatible Octave Debug Version.
And I am willing to upload it, in order that others can use it (size: 1 GB).
Included in this package is beside the "cmdshell.bat" also a "msys2_shell.cmd".
I have started the gdb-session in both shells, my impression is: "gdb.exe" works better
inside the "msys2_shell.cmd".

Please let me know if you would like to have my compile description for Ubuntu 20.04.

Attached the backtrace recorded with the debug-Version of Octave.

Regards,

Stefan

Am Di., 9. Juni 2020 um 14:51 Uhr schrieb Stefan Pofahl <[hidden email]>:
Hi,

I have reinstalled c++-libraries and I have installed the new Python-version v3.8.3:

@Markus:
Thanks for the advice and the link to download the c++-libraries!

Unfortunately, it has not cured the problem.

Attached the new backtrace ("bt").

Regards,

Stefan

Am Di., 9. Juni 2020 um 12:34 Uhr schrieb Markus Mützel <[hidden email]>:
Am 09. Juni 2020 um 12:17 Uhr schrieb "Stefan Pofahl":
> Sorry for the Typo ... See the attached tb-output ...

I was gasping again. But other than what you wrote in the mail body, you managed to enter the two letters in the correct order in gdb. Congratulations!

The crash occurs in the Visual C++ runtime libraries.

How did you install Python?

Maybe also try re-installing or repairing the Visual C++ runtime libraries. See e.g. here
https://support.microsoft.com/de-de/help/2977003/the-latest-supported-visual-c-downloads

Markus




--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001


--
Stefan Pofahl
Zollgasse 5
8020 Graz
Österreich
Tel.: +43 (316) 33 2001



back_trace_Py_Initialize_crash.txt (17K) Download Attachment