Re: Troubleshooting segmentation Violation Octave MXE 3.8.0 Win7 32bit

[Philip Nienhuis]

ijourneaux wrote
> Philip
> I am finally in a position where I can build Octave 3.8.1 for Windows
> (under Debian). Using the latest sources from
> http://hg.octave.org/mxe-octave, I was able to build the Octave install
> package and install on my windows machine.
> 
> At this point, I still get the same behavior I had observed before were I
> get a segmentation violation when I exit Octave after running this simple
> code
> 
> a = repmat (uint8 (0:255), 100, 1); 
> imwrite (a, "test.jpg"); 
> b=imrotate(a,5,'nearest','crop'); 
> 
> you had mentioned keeping the debug symbols but I have not been able to
> determine the correct change to make so that the debug symbols are kept.

Yes sorry I had no time & priority yet to sort this out. Good on you that
you came this far!

>From the top of my head, you'd need to proceed roughly as follows (hopefully
one of the other devs will jump in, undoubtedly I have some points wrong -
hopefully no vital ones). 
Note that my experiences with gdb are only basic. But it can't be much
different from or harder then the handful of other debuggers I used decades
ago, so here goes, two ways:

1. Rebuilding with debug symbols
-------------------------------
I think you need to change the install commands in the mxe-octave tree, in
<mxe-octave>/src/octave.mk (or .../stable-octave.mk).
IIRC somewhere there's a statement "install-strip" which has to be replaced
by a mere "install".
But it can also be in the top level Makefile.
I think that's about it for a start. Just build the installer then (make
nsis-installer JOBS=<nr_of_CPU_cores>)
Be warned that several dlls can get really large. IIRC one of the
liboct*.dll files, just built, is about 340 MB; after stripping it's just
some tens of MBs.

2. Replacing dlls with unstripped ones (not sure if this is actually true)
------------------------------------
You could also try to manually copy the relevant .dlls and .exes over from
<mxe-octave>/octave or from somewhere in
<mxe-octave>/usr/.../i686-mingw64.../bin. 
AFAIR somewhere in the mxe-octave source tree, after building the
installer/archive, they still exist in unstripped form. Maybe even in
<mxe-octave>/dist/octave-3.8.1 or so?
If you find them (compare their sizes versus the ones in your installation),
I think you can simply swap them into the place of the stripped ones in your
Octave installation. They are three liboct*.dll files and the various
octave*.exe files in bin/, plus the various .oct files in libexec/ and lib/.


To get a backtrace you'd need to setup a basic MinGW/MSYS setup in Windows
as outlined for the first steps of natively building an mxe-octave binary.
Once you have that, you can add the path to the installed Octave-3.8.1/bin
to the path in an MSYS/MinGW shell:
export PATH=/c/octave/octave-3.8.1/bin:$PATH:
(note drive syntax, here /c/ for c:\ ) and semicolon for path separator)
and then run octave in the debugger, along the lines of:

gdb octave-gui
run

<octave commands>

...and after a segfault:

bt

for the backtrace.

If this doesn't give clear pointers where the segfault occurs (e.g., when
you see something like "no symbols" in the backtrace) the segfault may have
happened somewhere in the dependencies. 
You might assess which dependency it is and then you can try to build that
with debug symbols. But I'm afraid that could be a bit harder.... so first
try to get started using the above hints.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Troubleshooting-segmentation-Violation-Octave-MXE-3-8-0-Win7-32bit-tp4662643p4663416.html
Sent from the Octave - General mailing list archive at Nabble.com.