Re: Octave 2.1 is segfaulting on hppa
In reference to a message from Dirk Eddelbuettel, dated May 13: Anew octave2.1_2.1.48 with debugging symbols is in ~edd on paer, could someone please install it? I can't convince octave to ignore its rpath so its looking at the non-debug version in /usr/lib/octave-2.1.48. Or else if there is a gdb trick, I'd take that too. LD_LIBRARY_PATH=... gdb fails as well. that's because octave uses rpath... sigh anyway, i suspect this is one of the many c++ bugs that has been fixed in g++-3.3. i tried to build octave with g++3.3 but it dies with some other error. can you try to get your package to build with g++-3.3 (any arch) and then we can see if that works better on hppa? with 3.2, it dies in #0 0x400c4098 in symbols_of_data() () #1 0x4031f3e0 in install_builtin_variables () at builtins.cc:849 #2 0x4031f730 in install_builtins() () at builtins.cc:961 #3 0x4030fd5c in octave_main (argc=114294784, argv=0x0, embedded=0) at octave.cc:408 #4 0x41738bd0 in __libc_start_main () from /lib/libc.so.6 #5 0x000105cc in _start () in symbols_of_data, the definition of some of the floating point constants is causing it to segfault. i'm not very sure why yet. HTH, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Re: Octave 2.1 is segfaulting on hppa
On Sun, May 18, 2003 at 02:03:28PM -0700, Randolph Chung wrote:
In reference to a message from Dirk Eddelbuettel, dated May 13:
Anew octave2.1_2.1.48 with debugging symbols is in ~edd on paer, could
someone please install it? I can't convince octave to ignore its rpath
so its looking at the non-debug version in /usr/lib/octave-2.1.48. Or
else if there is a gdb trick, I'd take that too. LD_LIBRARY_PATH=... gdb
fails as well.
that's because octave uses rpath... sigh
I know. John Eaton and I feel that rpath is justified as only Octave will
call the .so libraries built by/for Octave, and there is really no reason to
involve ldd. Use of rpath is a configure-time option, but I think it is
reasoable to use it on Debian.
anyway, i suspect this is one of the many c++ bugs that has been fixed
in g++-3.3. i tried to build octave with g++3.3 but it dies with some
other error. can you try to get your package to build with g++-3.3 (any
arch) and then we can see if that works better on hppa?
with 3.2, it dies in
#0 0x400c4098 in symbols_of_data() ()
#1 0x4031f3e0 in install_builtin_variables () at builtins.cc:849
#2 0x4031f730 in install_builtins() () at builtins.cc:961
#3 0x4030fd5c in octave_main (argc=114294784, argv=0x0, embedded=0)
at octave.cc:408
#4 0x41738bd0 in __libc_start_main () from /lib/libc.so.6
#5 0x000105cc in _start ()
in symbols_of_data, the definition of some of the floating point
constants is causing it to segfault. i'm not very sure why yet.
I got this (using the debug-symbol version finally installed by Martin)
which points to the STL, as least as I see it:
[EMAIL PROTECTED]:~$ dchroot sid
Executing shell in chroot: /org/paer.debian.org/chroot/sid
[EMAIL PROTECTED]:~$ gdb /usr/bin/octave2.1
GNU gdb 5.3-debian
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as hppa-linux...
(gdb) r
Starting program: /usr/bin/octave2.1
Program received signal SIGSEGV, Segmentation fault.
0x400c4698 in symbols_of_data() () at
/usr/include/c++/3.2/bits/stl_alloc.h:664
664 allocator() throw() {}
Current language: auto; currently c++
(gdb) s
p0x417ec850 in write () from /lib/libc.so.6
(gdb) l
659
660 templatetypename _Tp1
661 struct rebind
662 { typedef allocator_Tp1 other; };
663
664 allocator() throw() {}
665 allocator(const allocator) throw() {}
666 templatetypename _Tp1
667 allocator(const allocator_Tp1) throw() {}
668 ~allocator() throw() {}
Dirk
--
Don't drink and derive. Alcohol and analysis don't mix.
Octave 2.1 is segfaulting on hppa
Octave 2.1 is segfaulting on hppa, and this can be seen in the octave tests part of the buildd log for version 2.1.48-1: http://buildd.debian.org/fetch.php?pkg=octave2.1ver=2.1.48-1arch=hppastamp=1052279797file=logas=raw (look for segmentation fault there) Could a nice soul with debugging capabilities on a hppa Debian box try to understand what is going on? We need more information about the problem in order to send a bug report upstream. TIA, -- Rafael
Re: Octave 2.1 is segfaulting on hppa
On Tue, May 13, 2003 at 05:33:27PM +0200, Rafael Laboissiere wrote: Octave 2.1 is segfaulting on hppa, and this can be seen in the octave tests part of the buildd log for version 2.1.48-1: http://buildd.debian.org/fetch.php?pkg=octave2.1ver=2.1.48-1arch=hppastamp=1052279797file=logas=raw (look for segmentation fault there) Btw, that had been happening for a few releases now, it is not new in 2.1.48. Could a nice soul with debugging capabilities on a hppa Debian box try to understand what is going on? We need more information about the problem in order to send a bug report upstream. A freshly compiled version, with debugging symbols, sits in ~edd on paer in the sid chroot, but that box doesn't even have gdb installed ... Dirk -- Don't drink and derive. Alcohol and algebra don't mix.
Re: Octave 2.1 is segfaulting on hppa
On Tue, May 13, 2003 at 10:43:19AM -0500, Dirk Eddelbuettel wrote: Could a nice soul with debugging capabilities on a hppa Debian box try to understand what is going on? We need more information about the problem in order to send a bug report upstream. A freshly compiled version, with debugging symbols, sits in ~edd on paer in the sid chroot, but that box doesn't even have gdb installed ... installed now. -- It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject? -- Robert Fisk
Re: Octave 2.1 is segfaulting on hppa
A freshly compiled version, with debugging symbols, sits in ~edd on paer in the sid chroot, but that box doesn't even have gdb installed ... it does now. have fun :) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Re: Octave 2.1 is segfaulting on hppa
tausq, willy, On Tue, May 13, 2003 at 09:18:40AM -0700, Randolph Chung wrote: A freshly compiled version, with debugging symbols, sits in ~edd on paer in the sid chroot, but that box doesn't even have gdb installed ... it does now. have fun :) Thanks. Appears that I missed a dh_strip. Darn. Rebuilding now. May I utter a quick plea for help, though? I may not catch any subleties in why and where the platforms fails code that happily runs elsewhere. I'll report back when the rebuild is done. Executable will be ~edd/octave2.1-2.1.48/src/octave. Dirk -- Don't drink and derive. Alcohol and algebra don't mix.
Re: Octave 2.1 is segfaulting on hppa
Anew octave2.1_2.1.48 with debugging symbols is in ~edd on paer, could someone please install it? I can't convince octave to ignore its rpath so its looking at the non-debug version in /usr/lib/octave-2.1.48. Or else if there is a gdb trick, I'd take that too. LD_LIBRARY_PATH=... gdb fails as well. Dirk -- Don't drink and derive. Alcohol and algebra don't mix.
