[Bug libstdc++/41448] New: std::sort on std::vector with certain values leads to segfault in the vector destructor
I suffer strange segfault in program using std::sort on std::vector. The
segfault occures in destructor of sorted std::vector after several sort/clear
cycles. The values to reproduce the crash is actually decoded audio. I'm so
sorry, I can't evaluate the proper sequence of bad values so I've uploaded the
whole chunk here: http://downmusic.ru/test1 (110 mb sorry but i found no better
way...) I know it's not the ideal way but maybe it helps.
As far as I found out it is because of NaNs in float vector. Also,
std::stable_sort never leads to crash as I've tested.
--
Summary: std::sort on std::vector with certain values
leads to segfault in the vector destructor
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 4ernov at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41448] std::sort on std::vector with certain values leads to segfault in the vector destructor
--- Comment #1 from 4ernov at gmail dot com 2009-09-23 15:45 --- Created an attachment (id=18638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18638&action=view) The preprocessed file of the program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41448] std::sort on std::vector with certain values leads to segfault in the vector destructor
--- Comment #2 from 4ernov at gmail dot com 2009-09-23 15:47 --- Console output of g++ -v -save-temps -o gcc_sort -Wall -lQtCore -DQT_SHARED -I/usr/include/QtCore gcc_sort.cpp: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3.2/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,fortran,objc,treelang --disable-multilib --enable-c99 --enable-long-long Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcc_sort' '-Wall' '-DQT_SHARED' '-I/usr/include/QtCore' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/cc1plus -E -quiet -v -I/usr/include/QtCore -D_GNU_SOURCE -DQT_SHARED gcc_sort.cpp -mtune=generic -Wall -fpch-preprocess -o gcc_sort.ii ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/QtCore /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../include/c++/4.3.2 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../include/c++/4.3.2/x86_64-unknown-linux-gnu /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../include/c++/4.3.2/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcc_sort' '-Wall' '-DQT_SHARED' '-I/usr/include/QtCore' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/cc1plus -fpreprocessed gcc_sort.ii -quiet -dumpbase gcc_sort.cpp -mtune=generic -auxbase gcc_sort -Wall -version -o gcc_sort.s GNU C++ (GCC) version 4.3.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 181aa37d41253b88eaf3c45c4486e83b COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcc_sort' '-Wall' '-DQT_SHARED' '-I/usr/include/QtCore' '-shared-libgcc' '-mtune=generic' as -V -Qy -o gcc_sort.o gcc_sort.s GNU assembler version 2.18 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.18 COMPILER_PATH=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcc_sort' '-Wall' '-DQT_SHARED' '-I/usr/include/QtCore' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld-linux-x86-64.so.2 -o gcc_sort /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../lib/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/crtbegin.o -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../.. -lQtCore gcc_sort.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../lib/crtn.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41448] std::sort on std::vector with certain values leads to segfault in the vector destructor
--- Comment #3 from 4ernov at gmail dot com 2009-09-23 15:48 --- Created an attachment (id=18639) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18639&action=view) Source code that triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41448] std::sort on std::vector with certain values leads to segfault in the vector destructor
--- Comment #5 from 4ernov at gmail dot com 2009-09-23 16:04 --- Oh, I've tried to find info how the implementation manages NaNs but didn't find any clear info. So is it the expected behavior? And is it safe to use std::stable_sort for vectors with NaNs or I was just lucky? Actually, NaNs in the flow is an error in my program which I fixed, but I decided to save the faulty state to file the report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41448] std::sort on std::vector with certain values leads to segfault in the vector destructor
--- Comment #7 from 4ernov at gmail dot com 2009-09-24 18:39 --- Is there anything in C++ Standard concerning this case? Maybe it's more preferrable to throw exception or something like this.. Now it seems to make memory leak in the operated vector. The output is like this: *** glibc detected *** /usr/local/share/workspace/playground/gcc_sort: munmap_chunk(): invalid pointer: 0x01d2c550 *** *** glibc detected *** /usr/local/share/workspace/playground/gcc_sort: malloc(): memory corruption: 0x01d2bca0 *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41448] std::sort on std::vector with certain values leads to segfault in the vector destructor
--- Comment #10 from 4ernov at gmail dot com 2009-10-02 08:41 --- Yeah, I see.. But anyway, thank you for discussing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/43203] New: abi_check from libstdc++ tests fails with CFLAGS="-march=core2"
I've tried to built gcc-4.4.3 with different CFLAGS and CXXFLAGS variable and
have found that when they are "-march=core2" there's one unexpected failure in
libstdc++ tests: FAIL: abi_check. Everything else in test results is equal. I
know that I should build gcc with neither CFLAGS nor CXXFLAGS set but maybe
it's some kind of useful information.
--
Summary: abi_check from libstdc++ tests fails with CFLAGS="-
march=core2"
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 4ernov at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS="-march=core2"
--- Comment #1 from 4ernov at gmail dot com 2010-02-27 22:37 --- Created an attachment (id=19981) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19981&action=view) Test log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS="-march=core2"
--- Comment #3 from 4ernov at gmail dot com 2010-02-27 23:11 --- I'm sorry, I didn't write the title correctly, CXXFLAGS is the same value as CFLAGS in my case, i.e. CXXFLAGS is "-march=core2", too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS="-march=core2"
--- Comment #5 from 4ernov at gmail dot com 2010-02-27 23:37 --- Thank you for the problem description. But didn't completely understood: does it indicate any faults in my gcc build with this flags or is it just testsuite details and it's harmless? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS="-march=core2"
--- Comment #7 from 4ernov at gmail dot com 2010-02-27 23:54 --- Hmmm.. so it's also safe to build it with optimization, to say, -O2? Honestly, I was seriously convinced that it's dangerous because of big warnings in LFS etc. And I turned everything off every time.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS="-march=core2"
--- Comment #9 from 4ernov at gmail dot com 2010-02-28 00:14 --- Paolo, thank you very much for informing me and sorry for some off-topic, but it's so important for me, because obviously I was really confused. Thank you. And what about this report? Should we close it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS="-march=core2"
--- Comment #11 from 4ernov at gmail dot com 2010-02-28 00:21 --- Ok, thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
