|
Rodrigo Campos
|
Segfault in operator << of ostringstream
|
|
Rodrigo Campos
08/31/2010 2:42 PM
post65286
|
Segfault in operator << of ostringstream
Hi, I'm using C++ on QNX 6.3.2 and I got a segfault when doing "<<" in a ostringstream.
I've had a similar problem before[1] but it was because some library I was linking to was compiled against Dinkumware C+
+ Library and GNU C++ library, and there is a problem with Dinkumware C++ Library and multi-threaded programs (my
program is multi-thread). This problem in the library I was linking to was fixed (only links against GNU C++ if I'm not
wrong), but now I'm hitting a strange segfault too. Here is the backtrace:
(gdb) bt
#0 0xb0320ce4 in __flist_dequeue_bin () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#1 0xb0320791 in _list_release () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#2 0xb0320f41 in __prelocked_free () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#3 0xb0320ff0 in __free () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#4 0xb031ea4e in free () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#5 0xb824a718 in __builtin_vec_delete (ptr=0x8000004) at ../../gcc/cp/new2.cc:62
#6 0x080553d4 in stringbuf::overflow (this=0x7fa5ea4, c=124) at /opt/qnx632/target/qnx6/usr/include/g++-3/sstream:112
#7 0xb823b51d in __overflow () at ../../../../libstdc++/std/std_valarray.h:268
#8 0xb823b97c in _IO_default_xsputn () at ../../../../libstdc++/std/std_valarray.h:268
#9 0xb8244130 in streambuf::xsputn (this=0x7fa5ea4,
s=0x8202028 "CAL08|BAL01I|197.415|1282963716|A|0\nCAL08|BAL01I_F|NaN|1257376016|A|0\nCAL08|BAL02I|123.505|1282963716
|A|0\nCAL08|CD10_BTF1P_C|0|0|A|12\nCAL08|CD10_MATIAEP|0|0|A|12\nCAL08|CD10_MATIAOP|0|0|A|12\nCAL08|CD10"..., n=75290) at
../../../../libio/streambuf.cc:69
#10 0xb8242bdb in ostream::write (this=0x7fa5ea0,
s=0x8202028 "CAL08|BAL01I|197.415|1282963716|A|0\nCAL08|BAL01I_F|NaN|1257376016|A|0\nCAL08|BAL02I|123.505|1282963716
|A|0\nCAL08|CD10_BTF1P_C|0|0|A|12\nCAL08|CD10_MATIAEP|0|0|A|12\nCAL08|CD10_MATIAOP|0|0|A|12\nCAL08|CD10"..., n=75290) at
../../../../libio/iostream.cc:1004
#11 0x080538f6 in ostream & operator<<<char, string_char_traits<char>, __default_alloc_template<true, 0> > (o=@0x7fa5ea0, s=@
0x7fa5e94)
at /opt/qnx632/target/qnx6/usr/include/g++-3/std/bastring.cc:470
#12 0x08050db5 in UI_Comm::interpret_tokens (this=0x809b1a8, tokens=
{<_Vector_base<basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> >,allocator<
basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> > > >> = {<_Vector_alloc_base<basic_string<
char,string_char_traits<char>,__default_alloc_template<true,0> >,allocator<basic_string<char,string_char_traits<char>,
__default_alloc_template<true,0> > >,>> = {_M_start = 0x7fa5f48, _M_finish = 0x0, _M_end_of_storage = 0x0}, <No data
fields>}, <No data fields>})
at ui_comm.cc:206
#13 0x08051bd5 in UI_Comm::run (this=0x809b1a8) at ui_comm.cc:335
#14 0x08051a3a in UI_Comm::thread_run (arg=0x809b1a8) at ui_comm.cc:296
Till #12 is my program, after that it is inside the C++ library if I'm not wrong.
In this backtrace libcpp.so is not listed (at least directly, as it was in [1]) but I wanted to know if someone knows
something (perhaps something in the backtrace, that I don't know, is using libcpp ?) or is it a known problem that will
be fixed on an update ?
Thanks a lot,
Rodrigo
[1]: http://community.qnx.com/sf/discussion/do/listPosts/projects.community/discussion.qnx_momentics_community_support.
topc9455
|
|
|
|
|
|
Mario Charest
|
RE: Segfault in operator << of ostringstream
|
|
Mario Charest
08/31/2010 3:37 PM
post65302
|
RE: Segfault in operator << of ostringstream
From memory this was the same issue I had with dinkumware and multithread program... Fix was to upgrade to 6.4.1 ;-)
-----Message d'origine-----
De : Rodrigo Campos [mailto:community-noreply@qnx.com]
Envoyé : 31 août 2010 14:43
À : momentics-community
Objet : Segfault in operator << of ostringstream
Hi, I'm using C++ on QNX 6.3.2 and I got a segfault when doing "<<" in a ostringstream.
I've had a similar problem before[1] but it was because some library I was linking to was compiled against Dinkumware C+
+ Library and GNU C++ library, and there is a problem with Dinkumware C++ Library and multi-threaded programs (my
program is multi-thread). This problem in the library I was linking to was fixed (only links against GNU C++ if I'm not
wrong), but now I'm hitting a strange segfault too. Here is the backtrace:
(gdb) bt
#0 0xb0320ce4 in __flist_dequeue_bin () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#1 0xb0320791 in _list_release () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#2 0xb0320f41 in __prelocked_free () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#3 0xb0320ff0 in __free () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#4 0xb031ea4e in free () from /usr/qnx632/target/qnx6/x86/lib/libc.so.2
#5 0xb824a718 in __builtin_vec_delete (ptr=0x8000004) at ../../gcc/cp/new2.cc:62
#6 0x080553d4 in stringbuf::overflow (this=0x7fa5ea4, c=124) at /opt/qnx632/target/qnx6/usr/include/g++-3/sstream:112
#7 0xb823b51d in __overflow () at ../../../../libstdc++/std/std_valarray.h:268
#8 0xb823b97c in _IO_default_xsputn () at ../../../../libstdc++/std/std_valarray.h:268
#9 0xb8244130 in streambuf::xsputn (this=0x7fa5ea4,
s=0x8202028 "CAL08|BAL01I|197.415|1282963716|A|0\nCAL08|BAL01I_F|NaN|1257376016|A|0\nCAL08|BAL02I|123.505|1282963716
|A|0\nCAL08|CD10_BTF1P_C|0|0|A|12\nCAL08|CD10_MATIAEP|0|0|A|12\nCAL08|CD10_MATIAOP|0|0|A|12\nCAL08|CD10"..., n=75290) at
../../../../libio/streambuf.cc:69
#10 0xb8242bdb in ostream::write (this=0x7fa5ea0,
s=0x8202028 "CAL08|BAL01I|197.415|1282963716|A|0\nCAL08|BAL01I_F|NaN|1257376016|A|0\nCAL08|BAL02I|123.505|1282963716
|A|0\nCAL08|CD10_BTF1P_C|0|0|A|12\nCAL08|CD10_MATIAEP|0|0|A|12\nCAL08|CD10_MATIAOP|0|0|A|12\nCAL08|CD10"..., n=75290) at
../../../../libio/iostream.cc:1004
#11 0x080538f6 in ostream & operator<<<char, string_char_traits<char>, __default_alloc_template<true, 0> > (o=@0x7fa5ea0, s=@
0x7fa5e94)
at /opt/qnx632/target/qnx6/usr/include/g++-3/std/bastring.cc:470
#12 0x08050db5 in UI_Comm::interpret_tokens (this=0x809b1a8, tokens=
{<_Vector_base<basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> >,allocator<
basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> > > >> = {<_Vector_alloc_base<basic_string<
char,string_char_traits<char>,__default_alloc_template<true,0> >,allocator<basic_string<char,string_char_traits<char>,
__default_alloc_template<true,0> > >,>> = {_M_start = 0x7fa5f48, _M_finish = 0x0, _M_end_of_storage = 0x0}, <No data
fields>}, <No data fields>})
at ui_comm.cc:206
#13 0x08051bd5 in UI_Comm::run (this=0x809b1a8) at ui_comm.cc:335
#14 0x08051a3a in UI_Comm::thread_run (arg=0x809b1a8) at ui_comm.cc:296
Till #12 is my program, after that it is inside the C++ library if I'm not wrong.
In this backtrace libcpp.so is not listed (at least directly, as it was in [1]) but I wanted to know if someone knows
something (perhaps something in the backtrace, that I don't know, is using libcpp ?) or is it a known problem that will
be fixed on an update ?
Thanks a lot,
Rodrigo
[1]: http://community.qnx.com/sf/discussion/do/listPosts/projects.community/discussion.qnx_momentics_community_support.
topc9455
_______________________________________________
QNX Momentics Community...
|
|
|
|
|
|
Rodrigo Campos
|
Re: RE: Segfault in operator << of ostringstream
|
|
Rodrigo Campos
08/31/2010 6:51 PM
post65341
|
Re: RE: Segfault in operator << of ostringstream
> From memory this was the same issue I had with dinkumware and multithread
> program... Fix was to upgrade to 6.4.1 ;-)
>
But I'm not using dinkumware. I'm using the GNU C++ std library.
I've had a similar issue, but it was that a library I was linking to was linked against dinkumware[1]. Now that this
issue is fixed in the library, I'm seeing this backtrace.
I will recheck (I will not have access to the machine till tomorrow) if the fixed library is installed (and fixed), but
as the operator told me it was installed, I thought that, perhaps, there was some other issue.
Thanks a lot for your help, I will update the status tomorrow :)
Rodrigo
[1]: http://community.qnx.com/sf/discussion/do/listPosts/projects.community/discussion.qnx_momentics_community_support.
topc9455
|
|
|
|
|
|
Rodrigo Campos
|
Re: RE: Segfault in operator << of ostringstream
|
|
Rodrigo Campos
09/02/2010 11:46 AM
post65695
|
Re: RE: Segfault in operator << of ostringstream
> > From memory this was the same issue I had with dinkumware and multithread
> > program... Fix was to upgrade to 6.4.1 ;-)
>
> I will recheck (I will not have access to the machine till tomorrow) if the
> fixed library is installed (and fixed), but as the operator told me it was
> installed, I thought that, perhaps, there was some other issue.
Yes, the libraries I'm linking to does not link against libcpp.so
Here is the output of ldd of my binary:
libscanner.so => /opt/rf6/lib/libscanner.so (0xb8200000)
libstdc++.so.2.2.10.0 => /lib/libstdc++.so.2.2.10.0 (0xb821d000)
libm.so.2 => /lib/libm.so.2 (0xb826b000)
libsocket.so.2 => /lib/libsocket.so.2 (0xb8287000)
librf.so.1 => /opt/rf6/lib/librf.so.1 (0xb82ab000)
librfio.so => /opt/rf6/lib/librfio.so (0xb8315000)
libauth.so => /opt/rf6/lib/libauth.so (0xb831f000)
libhsc.so => /opt/rf6/lib/libhsc.so (0xb832c000)
libph.so.3 => /usr/lib/libph.so.3 (0xb8337000)
libphexlib.so.3 => /usr/lib/libphexlib.so.3 (0xb8437000)
librftrans.so => /opt/rf6/lib/librftrans.so (0xb8462000)
libflex.so => /opt/rf6/lib/libflex.so (0xb846e000)
librfhist.so => /opt/rf6/lib/librfhist.so (0xb84da000)
And here is the output of the libraries:
# ldd /opt/rf6/lib/lib*
/opt/rf6/lib/libauth.so:
libauth.so => /opt/rf6/lib/libauth.so (0xb8200000)
librf.so.1 => /opt/rf6/lib/librf.so.1 (0xb820d000)
librfio.so => /opt/rf6/lib/librfio.so (0xb8277000)
libsocket.so.2 => libsocket.so.2 (0xb8281000)
libm.so.2 => libm.so.2 (0xb82a5000)
libcpp.so.3 => libcpp.so.3 (0xb82c1000)
libhsc.so => /opt/rf6/lib/libhsc.so (0xb8335000)
libstdc++.so.2.2.10.0 => libstdc++.so.2.2.10.0 (0xb8340000)
/opt/rf6/lib/libcomm.so:
libcomm.so => /opt/rf6/lib/libcomm.so (0xb8200000)
/opt/rf6/lib/libflex.so:
libflex.so => /opt/rf6/lib/libflex.so (0xb8200000)
libm.so.2 => libm.so.2 (0xb826c000)
libsocket.so.2 => libsocket.so.2 (0xb8288000)
librf.so.1 => /opt/rf6/lib/librf.so.1 (0xb82ac000)
librfio.so => /opt/rf6/lib/librfio.so (0xb8316000)
libauth.so => /opt/rf6/lib/libauth.so (0xb8320000)
libflexuuid.so => /opt/rf6/lib/libflexuuid.so (0xb832d000)
libcpp.so.3 => libcpp.so.3 (0xb8331000)
libhsc.so => /opt/rf6/lib/libhsc.so (0xb83a5000)
libstdc++.so.2.2.10.0 => libstdc++.so.2.2.10.0 (0xb83b0000)
librfcrypt.so => /opt/rf6/lib/librfcrypt.so (0xb83fe000)
/opt/rf6/lib/libflexipc.so:
libflexipc.so => /opt/rf6/lib/libflexipc.so (0xb8200000)
libm.so.2 => libm.so.2 (0xb8207000)
libsocket.so.2 => libsocket.so.2 (0xb8223000)
librf.so.1 => /opt/rf6/lib/librf.so.1 (0xb8247000)
libcpp.so.3 => libcpp.so.3 (0xb82b1000)
libhsc.so => /opt/rf6/lib/libhsc.so (0xb8325000)
libstdc++.so.2.2.10.0 => libstdc++.so.2.2.10.0 (0xb8330000)
/opt/rf6/lib/libflexuuid.so:
libflexuuid.so => /opt/rf6/lib/libflexuuid.so (0xb8200000)
libsocket.so.2 => libsocket.so.2 (0xb8204000)
librfcrypt.so => /opt/rf6/lib/librfcrypt.so (0xb8228000)
libcpp.so.3 => libcpp.so.3 (0xb823b000)
/opt/rf6/lib/libfwhist.so:
libfwhist.so => /opt/rf6/lib/libfwhist.so (0xb8200000)
libflex.so => /opt/rf6/lib/libflex.so (0xb826b000)
libcpp.so.3 => libcpp.so.3 (0xb82d7000)
libm.so.2 => libm.so.2 (0xb834b000)
libsocket.so.2 => libsocket.so.2 (0xb8367000)
librf.so.1 => /opt/rf6/lib/librf.so.1 (0xb838b000)
librfio.so => /opt/rf6/lib/librfio.so (0xb83f5000)
libauth.so => /opt/rf6/lib/libauth.so (0xb83ff000)
libflexuuid.so => /opt/rf6/lib/libflexuuid.so (0xb840c000)
libhsc.so => /opt/rf6/lib/libhsc.so (0xb8410000)
libstdc++.so.2.2.10.0 => libstdc++.so.2.2.10.0 (0xb841b000)
librfcrypt.so => /opt/rf6/lib/librfcrypt.so (0xb8469000)
/opt/rf6/lib/libhsc.so:
libhsc.so => /opt/rf6/lib/libhsc.so (0xb8200000)
libstdc++.so.2.2.10.0 => libstdc++.so.2.2.10.0 (0xb820b000)
libm.so.2 => libm.so.2...
View Full Message
|
|
|
|
|
|
