[stlport-bugs] [ stlport-Bugs-1826271 ] Initialized Array of pair<int, string> cause core dump
Brought to you by:
complement
From: SourceForge.net <no...@so...> - 2007-11-13 13:19:44
|
Bugs item #1826271, was opened at 2007-11-05 13:44 Message generated for change (Comment added) made by liguosong 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: Liguo Song (liguosong) Date: 2007-11-13 08: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 06: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 15: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 11: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 03: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 14: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 |