Hi,
 
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int -> string, float -> string, double-> string).
After changing the ostringstream conversion to sprintf, the crash in the
application no more occured and the valgrind log was clear as well. It
seems the problem is in the str() function of ostringstream.
Consider the following test program in order to reproduce the bug:
 
#include <iostream>
#include <strstream>
#include <sstream>
#include <vector>
#include <string>
 
int main()
{
 
        std::vector<std::string> v;
        {
                std::ostringstream sstr;
                sstr << (double)1.12;
                v.push_back(sstr.str());
        }
 
        return 1;
}

 
The problem occured with gcc 3.4.2 and 3.4.4 compilers with -O2
optimization. Test program had been running both on 32 and 64 bit
architecture.
With O1 and O0 no problems was logged by valgrind. 3.2 and 4.0 compilers
the program was bug-free as well.
$ g++ -g -O2 -D__STL_DEBUG -DDEBUG test.c
 
valgrind tool signs the following problems:
==5443== Conditional jump or move depends on uninitialised value(s)
==5443==    at 0x11CD3445: std::string::string(std::string const&) (in
/usr/lib64/libstdc++.so.6.0.7)
==5443==    by 0x401907: std::vector<std::string,
std::allocator<std::string>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::string*,
std::vector<std::string, std::allocator<std::string> > >, std::string
const&) (new:92)
==5443==    by 0x40152E: main (stl_vector.h:330)
==5443== 
==5443== Conditional jump or move depends on uninitialised value(s)
==5443==    at 0x401585: main (basic_string.h:215)
==5443== 
==5443== Conditional jump or move depends on uninitialised value(s)
==5443==    at 0x401427: main (basic_string.h:215)
==5443== 
==5443== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 10 from 5)
==5443== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5443== malloc/free: 3 allocs, 3 frees, 574 bytes allocated.
==5443== For counts of detected errors, rerun with: -v
==5443== No malloc'd blocks -- no leaks are possible.

Do you have any idea for this issue?
 
Thanks and regards,
        Laszlo Jordan
 



Reply via email to