#152 Initialized Array of pair<int, string> cause core dump

5.1
closed-works-for-me
5
2014-08-14
2007-11-05
Liguo Song
No

VERSION: STLport 5.1.* (2, 3, and 4)
OS: SUSE LINUX Enterprise Server 9 (x86_64)
COMPILER: g++(GCC) 3.3.3 (SuSE Linux)

DESCRIPTION: All three versions compiled and tested OK. But, compile and execute the following code will cause core dump.

CODE:
#include <string>
#include <utility>

using namespace std;

int main() {

pair<int, string> PAIR_ARRAY[] = {
pair<int, string>(0, "0")
};

int PAIR_ARRAY_SIZE = sizeof(PAIR_ARRAY) > 0 ? sizeof(PAIR_ARRAY)/sizeof(PAIR_ARRAY[0]) : 0;

for (int i=0;i<PAIR_ARRAY_SIZE;i++) {
PAIR_ARRAY[i].second = "1";
}

return 0;
}

WORKAROUND: add -U_STLP_INTERNAL_PAIR_H seems to resolve this.

EXTRA INFORMATION:
1. This can only be produced on 64 bit platform described above. The same is OK on similar 32 bit platform;
2. PAIR_ARRAY_SIZE can be verified to have the right value of 1, with cout before the for-loop;
3. Earlier version STLport (4.6.*) was not tested, as the missing file src/c_locale_glibc/c_locale_glibc2.c pervented these version to be compiled on this platform;

Discussion

  • Liguo Song

    Liguo Song - 2007-11-05

    Logged In: YES
    user_id=1927618
    Originator: YES

    CORRECTION to WORKAROUND:
    It should really be not using STLport in -I option. -U_STLP_INTERNAL_PAIR_H doesn't help here.

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-06

    Logged In: YES
    user_id=615813
    Originator: NO

    You report is suspicious. Let me see lines of compilation and linking (_all_ options you pass to compiler/linker).

    About 4.6.x: _NO_ such release. Forget it. (it's was buggy when it was shipout, it has no explicit codebase, etc.)

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-06
    • assigned_to: nobody --> complement
     
  • Liguo Song

    Liguo Song - 2007-11-06

    Logged In: YES
    user_id=1927618
    Originator: YES

    Thanks for responding. It is good to get response even though it is suspicion.

    Here is the command lines used to compile and link in two steps, to honestly duplicate my compiling and linking procedure in my real projects:
    /usr/bin/g++ -g -pthread -I$HOME/Temp/STLport/STLport-5.1.4/stlport -I~/Temp/STLport/STLport-5.1.4/3.3.3 -c testSTLport.cpp -o testSTLport.o
    g++ -Wall -mt testSTLport.o -L$HOME/Temp/STLport/STLport-5.1.4/lib -lstlport -lpthread -o testSTLport

    And, the $LD_LIBRARY_PATH is set to $HOME/Temp/STLport/STLport-5.1.4/lib only.

    This causes Segmentation fault (core dump).

    Remove the -I options and the -L and -l options. The program compiles and links fine, and runs fine as the headers from libstdc++ works fine for pair. But, I have other libraries depend on stlport.

    Thanks again.

     
  • Francois Dumont

    Francois Dumont - 2007-11-12

    Logged In: YES
    user_id=1096600
    Originator: NO

    One suspicious thing on compilation: What is -I~/Temp/STLport/STLport-5.1.4/3.3.3 for ?

    Moreover you say that you have third parties library that need STLport. Have you rebuild those libs with the same STLport version you are using ?

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-13

    Logged In: YES
    user_id=615813
    Originator: NO

    ... and I would want to see postmortem stack trace too and ldd testSTLport. I'm really suspect the mix of STL implementations.

     
  • Liguo Song

    Liguo Song - 2007-11-13

    Logged In: YES
    user_id=1927618
    Originator: YES

    First of all, ~/Temp/STLport/STLport-5.1.4/3.3.3 is just a symlink to /usr/include/g++. Without this, STLport won't compile. (BTW, this is not in the INSTALL file.)

    Second, the libraries and my application are all rebuilt successfully against STLport-5.1.4, but my app starts to core dump after that. That's what led me to this bug hunt and STLport was the cause. That's why I get this simplified code which only relies on STLport to show the bug.

    Third, ldd testSTLport gives (home directory replaced by ~):
    libstlport.so.5.1 => ~/Temp/STLport/STLport-5.1.4/lib/libstlport.so.5.1 (0x0000002a9566d000)
    libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a9582d000)
    libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x0000002a95941000)
    libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95b1e000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a95c77000)
    libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95d82000)
    /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)

    Fourth, the stack trace for the core from gdb with bt command is:
    #0 0x0000002a95df3ad4 in memcpy () from /lib64/tls/libc.so.6
    #1 0x0000000000401b00 in stlp_std::__char_traits_base<char, int>::copy (__s1=0x100000030 <Address 0x100000030 out of bounds>, __s2=0x40259e "1", __n=1) at char_traits.h:178
    #2 0x00000000004017ac in stlp_std::basic_string<char, stlp_std::char_traits<char>, stlp_std::allocator<char> >::_M_assign (this=0x7fbfffefa8, __f=0x40259e "1", __l=0x40259f "") at _string.c:198
    #3 0x0000000000401425 in stlp_std::basic_string<char, stlp_std::char_traits<char>, stlp_std::allocator<char> >::operator= (this=0x7fbfffefa8, __s=0x40259e "1") at _string.h:383
    #4 0x000000000040132e in main () at testSTLport.cpp:17

    BTW, testSTLport.cpp:17 is : PAIR_ARRAY[i].second = "1";

    Thanks again for your time and assistance.

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-14

    Logged In: YES
    user_id=615813
    Originator: NO

    I add you testcase into SVN trunk (svn co https://stlport.svn.sourceforge.net/svnroot/stlport/trunk/STLport; export STLPORT_DIR=$PWD/STLport); build lib (cd ${STLPORT_DIR}/build/lib; make -f gcc.mak), build unit tests (cd ${STLPORT_DIR}/build/test/unit; make -f gcc.mak) and run ones (cd ${STLPORT_DIR}/build/test/unit; obj/gcc/so/stl_unit_test; obj/gcc/so_stlg/stl_unit_test) on you platform; report results here, please.

     
  • Francois Dumont

    Francois Dumont - 2007-11-14

    Logged In: YES
    user_id=1096600
    Originator: NO

    You will find explanation about the symbolic link you had to create in etc/FAQ. I understand why you had to create it but I don't understand why you had to pass it in compilation command. With trunk version you won't have to do so anymore.

     
  • Liguo Song

    Liguo Song - 2007-11-15

    Logged In: YES
    user_id=1927618
    Originator: YES

    Reply to complement:

    I checked out the source tree, and followed exact steps. Here are the result:

    1. Running obj/gcc/so/stl_unit_test, with earlier output skipped:

    ... ...
    NumPutGetTest::num_get_integer
    NumPutGetTest::inhex
    NumPutGetTest::pointer
    NumPutGetTest::fix_float_long
    OstreamIteratorTest::ostmit0
    PairTest::pair0
    PairTest::init

    Segmentation fault (core dumped)

    STACK TRACE of this core file in GDB gives:
    (gdb) where
    #0 0x0000002a95a9cad4 in memcpy () from /lib64/tls/libc.so.6
    #1 0x000000000041bd70 in stlp_std::basic_string<char, stlp_std::char_traits<char>, stlp_std::allocator<char> >::_M_assign ()
    #2 0x00000000004fb01a in PairTest::init ()
    #3 0x00000000004fb2e1 in PairTest::myRun ()
    #4 0x000000000040f6cf in TestCase::run ()
    #5 0x000000000040f844 in main ()

    2. Running obj/gcc/so_stlg/stl_unit_test:

    ... ...
    PairTest::pair0
    PairTest::init

    ../../../stlport/stl/debug/_iterator.h(173): STL assertion failure : _Incrementable(*this, __n, _Iterator_category())
    ../../../test/unit/pair_test.cpp(43) : CPPUNIT_CHECK(PAIR_ARRAY[i].second == "0");Aborted (core dumped)

    STACK TRACE in the core file in gdb gives:
    (gdb) where
    #0 0x0000002a95adf479 in raise () from /lib64/tls/libc.so.6
    #1 0x0000002a95ae0abf in abort () from /lib64/tls/libc.so.6
    #2 0x000000000042457b in stlpd_std::priv::__stl_debug_engine<bool>::_Terminate () at _debug.c:433
    #3 0x000000000042380e in stlpd_std::priv::__stl_debug_engine<bool>::_Assert (__expr=0x6bb748 "_Incrementable(*this, __n, _Iterator_category())", __f=0x6bb510 "../../../stlport/stl/debug/_iterator.h", __l=173)
    at _debug.c:425
    #4 0x000000000043c734 in stlpd_std::priv::_DBG_iter_base<stlpd_std::priv::_NonDbg_str<char, stlpd_std::char_traits<char>, stlpd_std::allocator<char> > >::__advance (this=0x7fbfffec90, __n=1) at _iterator.h:173
    #5 0x000000000043ba68 in stlpd_std::priv::_DBG_iter<stlpd_std::priv::_NonDbg_str<char, stlpd_std::char_traits<char>, stlpd_std::allocator<char> >, stlpd_std::priv::_DbgTraits<stlpd_std::_Nonconst_traits<char> > >::operator+ (this=0x7fbfffec70, __n=1) at _iterator.h:283
    #6 0x000000000043b8fe in stlpd_std::basic_string<char, stlpd_std::char_traits<char>, stlpd_std::allocator<char> >::_M_check_assign (this=0x7fbfffedf8, __n=1) at _string.h:330
    #7 0x000000000043b863 in stlpd_std::basic_string<char, stlpd_std::char_traits<char>, stlpd_std::allocator<char> >::assign (this=0x7fbfffedf8, __s=0x6eced5 "1") at _string.h:360
    #8 0x000000000042fd13 in stlpd_std::basic_string<char, stlpd_std::char_traits<char>, stlpd_std::allocator<char> >::operator= (this=0x7fbfffedf8, __s=0x6eced5 "1") at _string.h:175
    #9 0x000000000057369b in PairTest::init (this=0x96b580) at pair_test.cpp:44
    #10 0x000000000057399c in PairTest::myRun (this=0x96b580, in_name=0x6b9068 "", invert=false) at pair_test.cpp:16
    #11 0x000000000042272e in TestCase::run (in_reporter=0x970380, in_testName=0x6b9068 "", invert=false) at test_main.cpp:43
    #12 0x0000000000422974 in main (argc=1, argv=0x7fbffff038) at test_main.cpp:94

    Please let me know if I can provide any further information.

    Thanks.

     
  • Liguo Song

    Liguo Song - 2007-11-15

    Logged In: YES
    user_id=1927618
    Originator: YES

    Reply to dums:

    Sorry, I didn't dig deep enough to find the FAQ, as I find the solution quickly based on the error from compiler.

    And, you are right about the -I~/Temp/STLport/STLport-5.1.4/3.3.3. I can drop it in compilation, and it makes no difference whatsoever.

    Thanks for simplifying my compilation options.

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-20
    • status: open --> open-works-for-me
     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-20

    Logged In: YES
    user_id=615813
    Originator: NO

    Thanks to joebishop (aka Cheremisov Denis) for 64-bit linux, I checked this test. Problem not confirmed. You should search compiler problem or operational environment problem (when I do with 64-bit OpenSUSE 10.1 [not sure how SLES 9 correspond to Open SUSE] few years ago, it was ugly; 32-bit OpenSUSE 10.3 is fine, I just play with it on a few very different hardware).

    I run tests under environment:

    $ uname -a
    Linux vasya 2.6.22-14-generic #1 SMP Sun Oct 14 21:45:15 GMT 2007 x86_64 GNU/Linux
    $ c++ --version
    c++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
    Copyright (C) 2006 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.

    $ cat /proc/cpuinfo
    processor : 0
    vendor_id : AuthenticAMD
    cpu family : 15
    model : 107
    model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
    stepping : 1
    cpu MHz : 2505.223
    cache size : 512 KB
    physical id : 0
    siblings : 2
    core id : 0
    cpu cores : 2
    ...
    processor : 1
    vendor_id : AuthenticAMD
    cpu family : 15
    model : 107
    model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
    stepping : 1
    cpu MHz : 2505.223
    cache size : 512 KB
    physical id : 0
    siblings : 2
    core id : 1
    cpu cores : 2
    ...

    [Ubuntu 7.10]

     
  • Liguo Song

    Liguo Song - 2007-11-21

    Logged In: YES
    user_id=1927618
    Originator: YES

    Hi, Complement,

    Thanks for checking it out on the newer version of SUSE Linux, SLES 9 is really old as SLES 10 is already out for a while. But, working in a big company guarantees me the oldest workable OS. Do you believe that we just switched to Windows XP less than two years ago for our destktop? Anyway, I digress. ;(

    GCC 4.1.3 seems to be free of this issue, while GCC 3.3.3 is what I am using. I'll see whether I can make this happen.

    Thanks for all involved to narrow this down to a GCC version specific issue. This might worth a warning label for other users. Trust me, there are a lot people stuck with older GCC and OS.

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-21

    Logged In: YES
    user_id=615813
    Originator: NO

    Resume: not a STLport bug.

     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2007-11-21
    • status: open-works-for-me --> closed-works-for-me
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks