bugGNU Octave - Bugs: bug #36161, segfault when using octave_map...

 
 

bug #36161: segfault when using octave_map with g++ --std=c++11

Submitter:  None
Submitted:  Fri 13 Apr 2012 08:01:32 AM UTC
   
 
Category:  Libraries Severity:  2 - Minor
Priority:  3 - Low Item Group:  None
Status:  Works For Me Assigned to:  None
Originator Name:  fas Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 22 Jun 2013 12:59:02 PM UTC, comment #14: 

We have a report from Mike that this bug can no longer be reproduced with g++ 4.7.2 go it seems the bug was in g++ itself. We've also had no feedback opposing the result of Mike, so I'm closing this bug. It can always be reopened if its still a problem

D.

David Bateman <dbateman>
Group Member
Sat 20 Apr 2013 10:10:06 PM UTC, comment #13: 

I also cannot reproduce this:


$ g++-4.7 --version
g++-4.7 (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-4.7 -std=c++11 test.cpp -o test -I/usr/include/octave-3.6.4 -loctave -loctinterp
$ valgrind ./test


Output looks clean, no segfault. Also fine with 3.6.1 and development version. Does this still affect OP?

Mike Miller <mtmiller>
Group Member
Sat 14 Apr 2012 12:41:35 PM UTC, comment #12: 

Oh, sorry for the confusion! It did not occur to me that  it could be understood this way because I provided the sample code which breaks when compiled with this option.


Marko Bencun <fas2>
Sat 14 Apr 2012 12:34:08 AM UTC, comment #11: 

Ok.

My confusion was due to your original post with the subject: "[bug #36161] segfault when using octave_map with g++ --std=c++11"

From that I had inferred you only encountered the problem when you built octave with "--std=c++11"


Ben Abbott <bpabbott>
Group Member
Sat 14 Apr 2012 12:23:32 AM UTC, comment #10: 

Oh, but I did include this in my original report:

Compile and run with:

$ g++ --std=c++0x test.cpp -o test -I/usr/include/octave-3.6.1 -L/usr/lib/octave/3.6.1/ -loctave -loctinterp
$ LD_LIBRARY_PATH=/usr/lib/octave/3.6.1/ ./test


Use this to compile a file test.cpp with the following contents:


#include <octave/oct.h>
#include <octave/oct-map.h>

int main() {
    Octave_map map;
}

Best, Marko

Marko Bencun <fas2>
Fri 13 Apr 2012 11:57:33 PM UTC, comment #9: 

Marko,

What options do you use for configure ? There is no "--std" option.

What I was hoping for was a list of commands I could use to duplicate your results.

Ben Abbott <bpabbott>
Group Member
Fri 13 Apr 2012 11:15:47 PM UTC, comment #8: 

By the way, why is the status of this bug "Works For Me"? Did the one who changed it try it out with gcc 4.7.0 as I stated the original report?

Marko Bencun <fas2>
Fri 13 Apr 2012 11:04:14 PM UTC, comment #7: 

I confirm that the bug appears with gcc 4.7.0 and does not appear with earlier versions.

@jordigh

I realize this isn't a major bug. I just thought there was a chance that some core developer knew how to fix it right away and slip it in before the new release :)

I am not using octave to create oct files. I use it in some research code for my master thesis, and the whole project is compiled using c++11 (I use auto and lambdas all over the place).

I am also not using mkoctfile because my program is generated using CMake/Makefiles. Is there something inherently wrong with linking to the octave libs without mkoctfile?

@bpabbott:

> What do you change to enable c++11 support ?


What do you mean? I use the --std=c++11 flag to enable C++11 support.

For the time being, I can work around this bug  by removing the destructor (~dim_vector()) in dim_vector.h. I know it is not pretty, but I haven't found the real problem yet.

Marko Bencun <fas2>
Fri 13 Apr 2012 08:53:33 PM UTC, comment #6: 

I also can't reproduce this problem with GCC 4.6.2 on a Debian system.  There, valgrind gives me the following:


coredump:800> g++ --std=c++0x foo.cc -o foo -I/usr/local/octave/3.6.1/include/octave-3.6.1 -L/usr/local/octave/3.6.1/lib/octave/3.6.1 -loctave -loctinterp
coredump:801> ./foo
coredump:802> valgrind ./foo
==6514== Memcheck, a memory error detector
==6514== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==6514== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==6514== Command: ./foo
==6514==
==6514==
==6514== HEAP SUMMARY:
==6514==     in use at exit: 1,338 bytes in 38 blocks
==6514==   total heap usage: 5,410 allocs, 5,372 frees, 293,247 bytes allocated
==6514==
==6514== LEAK SUMMARY:
==6514==    definitely lost: 60 bytes in 1 blocks
==6514==    indirectly lost: 240 bytes in 10 blocks
==6514==      possibly lost: 662 bytes in 19 blocks
==6514==    still reachable: 376 bytes in 8 blocks
==6514==         suppressed: 0 bytes in 0 blocks
==6514== Rerun with --leak-check=full to see details of leaked memory
==6514==
==6514== For counts of detected and suppressed errors, rerun with: -v
==6514== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
coredump:803> gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.6.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-12' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.2 (Debian 4.6.2-12)


John W. Eaton <jwe>
Group administrator
Fri 13 Apr 2012 01:43:38 PM UTC, comment #5: 

By the way, you should be compiling with mkoctfile:


CXXFLAGS='-std=c++0x' mkoctfile test.cc --link-stand-alone


I can't reproduce this valgrind output on gcc 4.4.5, so I'm inclined to think it's the compiler that's at fault, not Octave.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Fri 13 Apr 2012 01:35:09 PM UTC, comment #4: 

This is a minor bug and certainly not release-critical. The workaround is simple: don't compile with -std=c++11. This will not be fixed for the 3.6.2 series.

Octave is still some time away from allowing C++11 features, because the compilers themselves haven't caught on. You will have to rely in the meantime in C++03 for your oct files.

If you care deeply about this issue, clone our hg repo and start hacking on it:

http://hg.savannah.gnu.org/hgweb/octave/

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Fri 13 Apr 2012 01:34:04 PM UTC, comment #3: 

What do you change to enable c++11 support ?

Ben Abbott <bpabbott>
Group Member
Fri 13 Apr 2012 12:43:42 PM UTC, comment #2: 

I installed octave using pacman in Archlinux.

The relevant part of the PKBUILD:


  cd ${srcdir}/${pkgname}-${pkgver}

  # http://www.nabble.com/Random-rounding-errors-td16010966.html
  FFLAGS="-O -ffloat-store" \

  ./configure --prefix=/usr --libexecdir=/usr/lib \
  --enable-shared --disable-static

  LANG=C make

Any more infos I can provide?

Marko Bencun <fas2>
Fri 13 Apr 2012 12:20:05 PM UTC, comment #1: 

Please provide more information. What commands did you use to build Octave 3.6.1?

Ben Abbott <bpabbott>
Group Member
Fri 13 Apr 2012 08:01:32 AM UTC, original submission:  

A segfault occurs when the following code is compiled with c++11 support. Without c++11 support, there is no problem.


Using g++ (GCC) 4.7.0 20120407 on Archlinux 64 bit.

Short code to reproduce:

#include <octave/oct.h>
#include <octave/oct-map.h>
 
int main() {
  Octave_map map;
}


Compile and run with:

$ g++ --std=c++0x test.cpp -o test -I/usr/include/octave-3.6.1 -L/usr/lib/octave/3.6.1/ -loctave -loctinterp
$ LD_LIBRARY_PATH=/usr/lib/octave/3.6.1/ ./test

Valgrind output:

==22564== Use of uninitialised value of size 8
==22564==    at 0x401E74: dim_vector::~dim_vector() (dim-vector.h:257)
==22564==    by 0x402246: Octave_map::~Octave_map() (in /home/marko/test/test)
==22564==    by 0x401A7A: main (test.cpp:5)
==22564==
-402653184
==22564== Use of uninitialised value of size 8
==22564==    at 0x401E9B: dim_vector::~dim_vector() (dim-vector.h:258)
==22564==    by 0x402246: Octave_map::~Octave_map() (in /home/marko/test/test)
==22564==    by 0x401A7A: main (test.cpp:5)
==22564==
==22564==
==22564== Process terminating with default action of signal 11 (SIGSEGV)
==22564==  Bad permissions for mapped region at address 0x401B2C
==22564==    at 0x401EA0: dim_vector::~dim_vector() (dim-vector.h:258)
==22564==    by 0x402246: Octave_map::~Octave_map() (in /home/marko/test/test)
==22564==    by 0x401A7A: main (test.cpp:5)
==22564==
==22564== HEAP SUMMARY:
==22564==     in use at exit: 424,342 bytes in 3,613 blocks
==22564==   total heap usage: 5,435 allocs, 1,822 frees, 528,542 bytes allocated
==22564==
==22564== LEAK SUMMARY:
==22564==    definitely lost: 0 bytes in 0 blocks
==22564==    indirectly lost: 0 bytes in 0 blocks
==22564==      possibly lost: 289,624 bytes in 1,375 blocks
==22564==    still reachable: 134,718 bytes in 2,238 blocks
==22564==         suppressed: 0 bytes in 0 blocks
==22564== Rerun with --leak-check=full to see details of leaked memory
==22564==
==22564== For counts of detected and suppressed errors, rerun with: -v
==22564== Use --track-origins=yes to see where uninitialised values come from
==22564== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 3 from 3)

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #25636:  test.cpp added by None (313B - text/x-c++src)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-06-22 dbateman Open/ClosedOpen Closed
    2013-04-20 mtmiller CategoryNone Libraries
    2012-04-13 jordigh StatusNeed Info Works For Me
    2012-04-13 jordigh Severity3 - Normal 2 - Minor
        Priority5 - Normal 3 - Low
    2012-04-13 bpabbott StatusNone Need Info
    2012-04-13 None Attached File- Added test.cpp, #25636

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code