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.
|
Sat 20 Apr 2013 10:10:06 PM UTC, comment #13:
I also cannot reproduce this:
Output looks clean, no segfault. Also fine with 3.6.1 and development version. Does this still affect OP?
|
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.
|
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"
|
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
|
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.
|
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?
|
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.
|
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:
|
Fri 13 Apr 2012 01:43:38 PM UTC, comment #5:
By the way, you should be compiling with mkoctfile:
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.
|
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/
|
Fri 13 Apr 2012 01:34:04 PM UTC, comment #3:
What do you change to enable c++11 support ?
|
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?
|
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?
|
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)
|