bugGNU Octave - Bugs: bug #38175, 3.6.4rc1 doesn't build with...

 
 

bug #38175: 3.6.4rc1 doesn't build with gfortran from gcc 4.7, script never exits after segfault

Submitted by:  John Marino <jrmarino>
Submitted on:  Sun 27 Jan 2013 10:56:06 AM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: InvalidAssigned to: None
Originator Name: John MarinoOpen/Closed: Closed
Release: devOperating System: BSD

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 31 Jan 2013 06:37:47 PM UTC, comment #11:

I think it was a very specific case with <iostream> because the majority of c++ programs build fine with no runtime error reports.

However, I managed to track down the source of the problem and I patched both the system compiler and this gcc47/gfortran ports compiler.

Now octave 3.6.3 builds successfully in pkgsrc and octave 3.6.4-rc1 just finished building successfully in ports.

So yes, it was a compiler fault causing this.
It still hung due to a real segfault but I agree that's extenuating and not worth pursuing.

Thanks for helping me find the backtrace which lead to the compiler fixes.

John Marino <jrmarino>
Wed 30 Jan 2013 03:41:39 PM UTC, comment #10:

If the simple C++ program in the DragonFlyBSD report is segfaulting for you, there is no hope for Octave's usage of std::string to work either. So I am inclined to say that this is a compiler problem. I am closing this bug report. If you disagree, let me know and we can reopen it.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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.

John Marino <jrmarino>
Mon 28 Jan 2013 10:07:58 PM UTC, comment #8:

Ah, hold on.
gsed was specified and present. It just wasn't on the system when the wrkdirs were run. Let me try that command again with gsed present.

John Marino <jrmarino>
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)

John Marino <jrmarino>
Mon 28 Jan 2013 07:57:18 PM UTC, comment #6:

Okay, this is going to take longer to reproduce than I thought.
3.6.4-rc1 just fully built and installed on the new x86_64 machine (not a bulk build, just a standard make; make install from ports)

John Marino <jrmarino>
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.

John Marino <jrmarino>
Mon 28 Jan 2013 05:25:30 PM UTC, comment #4:

No, this isn't normal, not for the command that run-octave executed.

I don't think the problem is run-octave. You should see that the process that is chewing CPU is 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.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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.

John Marino <jrmarino>
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.

John Marino <jrmarino>
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.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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

      • Error code 1
John Marino <jrmarino>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by jrmarino (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 30 Jan 2013 03:41:39 PM UTCjordighStatusNeed Info=>Invalid
      Open/ClosedOpen=>Closed
    Mon 28 Jan 2013 04:19:47 PM UTCjordighStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1