[stlport-bugs] [ stlport-Bugs-1826271 ] Initialized Array of pair<int, string> cause core dump

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1826271, was opened at 2007-11-05 19:44
Message generated for change (Comment added) made by dums
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1826271&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Operational Environment/Compiler specific code
Group: 5.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Liguo Song (liguosong)
Assigned to: Petr Ovtchenkov (complement)
Summary: Initialized Array of pair<int, string> cause core dump

Initial Comment:
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;

----------------------------------------------------------------------

>Comment By: Francois Dumont (dums)
Date: 2007-11-14 10:26

Message:
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.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-11-14 07:16

Message:
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.

----------------------------------------------------------------------

Comment By: Liguo Song (liguosong)
Date: 2007-11-13 14:19

Message:
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.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-11-13 12:08

Message:
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.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-11-12 21:49

Message:
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 ?

----------------------------------------------------------------------

Comment By: Liguo Song (liguosong)
Date: 2007-11-06 17:18

Message:
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.

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-11-06 09:34

Message:
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.)

----------------------------------------------------------------------

Comment By: Liguo Song (liguosong)
Date: 2007-11-05 20:47

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1826271&group_id=146814