Mon 28 Jan 2013 10:43:48 PM UTC, comment #9:
Okay, after adding a bunch of missing dependencies in the real environment, I was finally able to get a trace (below).
It is possible there is a problem with the compiler. While this is not the DragonFly system compiler, it is very similar to it. This bug report seems similar: http://bugs.dragonflybsd.org/issues/2478
So based on this trace and that other bug report, does this look like a compiler issue or an octave issue to you guys?
Program received signal SIGSEGV, Segmentation fault.
0x0000000806b7464e in std::istream::sentry::sentry(std::istream&, bool) ()
from /usr/local/gcc-aux/lib/libstdc++.so.6
#0 0x0000000806b7464e in std::istream::sentry::sentry(std::istream&, bool) ()
from /usr/local/gcc-aux/lib/libstdc++.so.6
#1 0x0000000806b6dff3 in std::basic_istream<char, std::char_traits<char> >& std::operator>><char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) () from /usr/local/gcc-aux/lib/libstdc++.so.6
#2 0x0000000800ca50ab in parse_save_options(std::string const&, load_save_format&, bool&, bool&, bool&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#3 0x0000000800ca6503 in Fsave(octave_value_list const&, int) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#4 0x0000000800df57d5 in octave_builtin::do_multi_index_op(int, octave_value_list const&, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#5 0x0000000800df468d in octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#6 0x0000000800df532b in octave_builtin::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#7 0x0000000800e88f0a in octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#8 0x0000000800e88f45 in octave_value::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#9 0x0000000800efcc9b in tree_index_expression::rvalue(int, std::list<octave_lvalue, std::allocator<octave_lvalue> > const*) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#10 0x0000000800efceae in tree_index_expression::rvalue(int) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#11 0x0000000800efa703 in tree_index_expression::rvalue1(int) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#12 0x0000000800ef4de5 in tree_evaluator::visit_statement(tree_statement&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#13 0x0000000800f0e988 in tree_statement::accept(tree_walker&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#14 0x0000000800ef45a9 in tree_evaluator::visit_statement_list(tree_statement_list&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#15 0x0000000800f0ea48 in tree_statement_list::accept(tree_walker&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#16 0x0000000800e7e8a4 in octave_user_script::do_multi_index_op(int, octave_value_list const&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#17 0x0000000800cf5fb9 in source_file(std::string const&, std::string const&, bool, bool, std::string const&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#18 0x0000000800d5313b in safe_source_file(std::string const&, std::string const&, bool, bool, std::string const&) ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#19 0x0000000800d56ec2 in octave_main ()
from /wrkdirs/math/octave/work/octave-3.6.4-rc1/src/.libs/liboctinterp.so.1
#20 0x0000000000400aaa in main ()
A debugging session is active.
Inferior 1 [process 95422] will be killed.
|
Mon 28 Jan 2013 09:56:53 PM UTC, comment #7:
Okay, this looks like gsed was an undocumented dependency. In these bulk environments, only specified dependencies are loaded in them and gsed wasn't specified. I'll try again with gsed listed as a dependency.
1) Is posix sed really not good enough?
2) FYI, it was "octave" not "lt-octave" that had 97% CPU.
3) The regular build probably worked because something along the way installed gsed and it was present
output of -g command below:
dfly# ../../run-octave -g -f -q -H ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS
../../run-octave: /usr/local/bin/gsed: not found
../../run-octave: /usr/local/bin/gsed: not found
../../run-octave: /usr/local/bin/gsed: not found
GNU gdb (GDB) 7.4.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-dragonfly".
For bug reporting instructions, please see:
<http://bugs.dragonflybsd.org/>...
"/home/marino/wkzone/octave-work/octave-3.6.4-rc1/src/octave": not in executable
format: File format not recognized
(gdb)
|
Mon 28 Jan 2013 05:33:44 PM UTC, comment #5:
"Is it lt-octave or something like that. I don't understand why it's doing that instead of quitting. Are we perhaps handling SIGSEGV incorrectly on BSD? If so, we may have to handle this problem before you're able to produce a segfault."
I believe it is lt-octave that showed in top with 97%. I couldn't remember the name, only that it started with "lt-"
I am attempting to recreate this on a different machine. with pkgsrc and v3.6.2, I used an i386. With 3.6.4-rc1, I used x86_64. I am trying on a different x86_64 now since I lost access to the original one.
It will take a while to build up all the dependencies though.
|
Mon 28 Jan 2013 05:14:24 PM UTC, comment #3:
"I very much don't see this. Are you sure it's genuinely hanging or is Octave just taking a long time to save the workspace? Do you see any CPU activity? (It's not really a core dump, when Octave crashes, it tries to save the current workspace.) Furthermore, run-octave is a very simple bash script for running Octave in the build dir, you can read it yourself. This should not be the source of trouble with the build hanging."
To address this closer:
1. long time? How long is long? is 30 minutes normal? An hour? I've seen this package locked at least that long.
2. CPU activity? CPU is at 97%+ without change until it is killed
How big can the workspace be during this build step? Yes, I assume 30 - 60 minutes more than enough time to save its workspace.
|
Mon 28 Jan 2013 05:08:26 PM UTC, comment #2:
okay, I'll try to get a stacktrace but I have to set things up to do it. It was in a builder that automatically flushes the wrkdirs before.
" The second issue is that the build script hangs if run-octave segfaults. [I very much don't see this.]"
Well, it happens 100% of the time when being built in pkgsrc and ports. It causes a bulk build to completely stop in pkgsrc (because they are serial) and it logs up a core set in ports (poudriere has parallel builds). This isn't new, it's been doing it as long as I've tried to build with gcc 4.7.
Actually I'm using DragonFly BSD. It can build from FreeBSD's ports. I can guarantee all fortran packages are built with the same fortran compiler (as there is only one available).
Especially with gcc handling, there is significant difference between FreeBSD and DragonFly while building ports. The two platforms don't build octave with the same compiler (even if it did, gcc has a lot of system-specific config files). Fortran on DragonFly passes very high on the gcc testsuite though, at least as high as FreeBSD.
|
Mon 28 Jan 2013 04:19:47 PM UTC, comment #1:
> It always segfaults during the build.
Can you please produce a stack trace? Go into /wrkdirs/math/octave/work/octave-3.6.4-rc1/doc/interpreter, execute the same run-octave command but prepend -g, and then follow these instructions:
http://wiki.octave.org/Debugging_Octave#Producing_a_stack_trace
> The second issue is that the build script hangs if run-octave segfaults.
I very much don't see this. Are you sure it's genuinely hanging or is Octave just taking a long time to save the workspace? Do you see any CPU activity? (It's not really a core dump, when Octave crashes, it tries to save the current workspace.) Furthermore, run-octave is a very simple bash script for running Octave in the build dir, you can read it yourself. This should not be the source of trouble with the build hanging.
Also, since you're using FreeBSD, I assume you're building everything from source yourself. If so, are you using the same gfortran version for building Octave as well as its BLAS dependencies and any other Fortran dependencies? It's very easy to miscompile a BLAS. Are you sure that part is working correctly? I'm halfway through a FreeBSD ports build myself, but I had already started some ports on an older gcc before bootstrapping a newer one, so I had to restart everything with the same gcc.
|
Sun 27 Jan 2013 10:56:06 AM UTC, original submission:
For several months, I've tried building octave with fortran from gcc 4.7. It always segfaults during the build. I had hoped that 3.6.4rc1 would finally address this, but it does not.
Before 3.6.4 is released, please fix it for the current gcc.
The second issue is that the build script hangs if run-octave segfaults. On both pkgsrc and FreeBSD ports, the build will never exit because whatever calls run-octave never figures out that run-octave panicked. Perhaps some kind of exit code could be added to the "stopping myself" routine so that scripts can gracefully exit.
As you can see from the build log excerpt below, the script had to forcibly called after the panic.
=====================================
rm -rf $backupdir; exit $rc
../../run-octave -f -q -H ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS || { rm -f doc-cache; exit 1; }
warning: X11 DISPLAY environment variable not set
panic: Segmentation fault: 11 -- stopping myself...
attempting to save variables to 'octave-core'...
attempting to save variables to 'octave-core'...
Killed
gmake[3]: *** [doc-cache] Error 1
gmake[3]: Leaving directory `/wrkdirs/math/octave/work/octave-3.6.4-rc1/doc/interpreter'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/wrkdirs/math/octave/work/octave-3.6.4-rc1/doc'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/wrkdirs/math/octave/work/octave-3.6.4-rc1'
gmake: *** [all] Error 2
|