Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 64819 - Octave with shared libraries segfaults with gcc-3.4.x
Summary: Octave with shared libraries segfaults with gcc-3.4.x
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Science Related Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-20 21:50 UTC by texon
Modified: 2005-12-16 16:26 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description texon 2004-09-20 21:50:43 UTC
When the default octave package from 'emerge octave' is built with the new gcc-3.4.1-r3 (or any gcc-3.4.x) it gives a segmentation fault when run.  Octave builds fine, and by default uses -fPIC shared libraries.  If the .ebuild file is modified to use static, then the resulting octave builds and runs.

Reproducible: Always
Steps to Reproduce:
1. emerge gcc   (with gcc-3.4.x)
2. emerge octave
3. ./octave

Actual Results:  
free(): invalid pointer 0x8a51fd8!
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-core'...
save to 'octave-core' complete
Segmentation fault

Expected Results:  
octave>

If you comment out the "use static ||..." line in the ebuild for octave-2.1.57-x
then octave builds fine with CFLAGS="-march=athlon -O2 -pipe", but by default
the version with shared libraries gives the segfault.  Using -march=i486 doesn't
help either.
Comment 1 Michael Gaber 2005-06-10 10:39:10 UTC
same thing here, octave just won't work 
Comment 2 TorbaX 2005-08-17 17:50:00 UTC
(In reply to comment #0)
> When the default octave package from 'emerge octave' is built with the new
gcc-3.4.1-r3 (or any gcc-3.4.x) it gives a segmentation fault when run.  Octave
builds fine, and by default uses -fPIC shared libraries.  If the .ebuild file is
modified to use static, then the resulting octave builds and runs.
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. emerge gcc   (with gcc-3.4.x)
> 2. emerge octave
> 3. ./octave
> 
> Actual Results:  
> free(): invalid pointer 0x8a51fd8!
> panic: Segmentation fault -- stopping myself...
> attempting to save variables to 'octave-core'...
> save to 'octave-core' complete
> Segmentation fault
> 
> Expected Results:  
> octave>
> 
> If you comment out the "use static ||..." line in the ebuild for octave-2.1.57-x
> then octave builds fine with CFLAGS="-march=athlon -O2 -pipe", but by default
> the version with shared libraries gives the segfault.  Using -march=i486 doesn't
> help either.

Hello,

With my computer Octave works correctly.

I've installed:
i686-pc-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)
"OCTAVE 2.1.69"
"GLIBC-1.2.10"

On "/etc/make.conf" I set:
CFLAGS="-O9 -march=athlon-xp -fomit-frame-pointer -ffast-math"

No USE flag I set to compile Octave... 
(I left default USE flags specified for Octave)
USE="-blas -emacs -hdf5 -ifc -mpi +readline -static +tetex +zlib"

then After I did:
# emerge octave
# ./octave
GNU Octave, version 2.1.69 (i686-pc-linux-gnu).
...
(cut)
(cut)

...
octave:1> y = [1 3 4 2 1 5 3 5 6 7 4 5 7 10 11 3];
octave:2> g = [1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3];
octave:3> anova(y,g);

One-way ANOVA Table:

Source of Variation   Sum of Squares    df  Empirical Var
*********************************************************
Between Groups               72.3903     2        36.1951
Within Groups                58.7619    13         4.5201
---------------------------------------------------------
Total                       131.1522    15

Test Statistic f              8.0075
p-value                       0.0054

octave:4> quit

#


It's Ok, Octave works and didn't crash.

Bye.
TorbaX.


Comment 3 Andrew 2005-11-11 23:07:29 UTC
I also had this problem on a pentium-m machine with gcc-3.4.4.  The output after
trying to run octave was,

panic: Aborted -- stopping myself...
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create
panic: attempted clean up apparently failed -- aborting...
Aborted
Comment 4 Jonathan Halcrow 2005-12-07 16:44:24 UTC
I think I've figured it out.  Checking the bt from octave gives a hint:   
   
#3  0xa5dffff8 in std::basic_string<char, std::char_traits<char>,   
std::allocator<char> >::basic_string   
    () from /usr/lib/libstdc++-v3/libstdc++.so.5   
#4  0xa5e63574 in Fdispatch_help ()   
     
from /usr/libexec/octave/2.1.69/site/oct/i686-pc-linux-gnu/octave-forge/dispatch.oct   
#5  0xa5e64286 in Fdispatch ()   
   
Octave uses octave-forge on startup.  But, octave-forge depends on octave, so   
when you do `emerge -e world` after updating gcc-3.3 -> 3.4, octave is rebuilt   
to use gcc-3.4 at some point.   Meanwhile octave-forge is using gcc-3.3.  At   
this point octave is borked.  Then when emerge gets to octave-forge, the build   
fails because octave is run (and promptly dies) during the configure stage of   
octave-forge.  For some reason octave-forge doesn't let a little thing like a   
segfault stop it, and keeps right on building.  10 minutes later, the build   
fails as a direct result of the borked configuration.  In the end, you're left   
with octave unable to start, since octave-forge is still out of date.  The   
answer is:  
   
emerge -C octave-forge   
emerge octave-forge   
  
So I guess the bug is with octave-forge?  
Comment 5 Mark Loeser (RETIRED) gentoo-dev 2005-12-09 20:41:14 UTC
As the last comment says, you need to have everything compiled with gcc-3.4, so
this isn't a gcc-porting problme.

I don't know if the sci team wants to fix the configure so it actually works
properly, so I'm reassigning this to them so they can decide.
Comment 6 Marcus D. Hanwell (RETIRED) gentoo-dev 2005-12-16 16:26:57 UTC
I think that this is covered by the upgrade guide, but basically a lot of apps break when you mix 3.3 and 3.4 (or 4.0 for that matter). I am not certain how the configure script should be changed to account for this, but many things break if you do not recompile your entire system. Marking as WORKSFORME on a pure GCC 3.4 system.