Question

I have valgrind 3.6.0, I’ve searched everywhere and found nothing.

The problem is that when I’m trying to access a float number while using valgrind, I get a segfault, but when I run the program as is, without valgrind, everythings goes as expected.

This is the piece of code:

class MyClass {
    public:
    void end() {
        float f;
        f = 1.23;
        std::stringstream ss;
        ss << f;
        std::cout << ss.str();
    }
};

extern "C" void clean_exit_on_sig(int sig) {
    //Code logging the error
    mc->end();
    exit(1);
}

MyClass *mc;
int main(int argc, char *argv[]) {
    signal(SIGINT , clean_exit_on_sig);
    signal(SIGABRT , clean_exit_on_sig);
    signal(SIGILL , clean_exit_on_sig);
    signal(SIGFPE , clean_exit_on_sig);
    signal(SIGSEGV, clean_exit_on_sig);
    signal(SIGTERM , clean_exit_on_sig);
    mc = new MyClass();
    while(true) {
        // Main program loop
    }
}

When I press Control+C, the program catches the signal correctly and everything goes fine, but when I run the program using valgrind, when tries to execute this command ss << f; // (Inside MyClass) a segfault is thrown :-/

I’ve tried this too:

std::string stm = boost::lexical_cast<std::string>(f);

But I keep on receiving a segfault signal when boost acceses the float number too.

This is the backtrace when I get segfault with boost:

./a.out(_Z17clean_exit_on_sigi+0x1c)[0x420e72]
/lib64/libc.so.6(+0x32920)[0x593a920]
/usr/lib64/libstdc++.so.6(+0x7eb29)[0x51e6b29]
/usr/lib64/libstdc++.so.6(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE15_M_insert_floatIdEES3_S3_RSt8ios_baseccT_+0xd3)[0x51e8f43]
/usr/lib64/libstdc++.so.6(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecd+0x19)[0x51e9269]
/usr/lib64/libstdc++.so.6(_ZNSo9_M_insertIdEERSoT_+0x9f)[0x51fc87f]
./a.out(_ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_E9lcast_putIfEEbRKT_+0x8f)[0x42c251]
./a.out(_ZN5boost6detail26lexical_stream_limited_srcIcSt15basic_streambufIcSt11char_traitsIcEES4_ElsEf+0x24)[0x42a150]
./a.out(_ZN5boost6detail12lexical_castISsfLb0EcEET_NS_11call_traitsIT0_E10param_typeEPT2_m+0x75)[0x428349]
./a.out(_ZN5boost12lexical_castISsfEET_RKT0_+0x3c)[0x426fbb]
./a.out(This line of code corresponds to the line where boost tries to do the conversion)

and this is with the default stringstream conversion:

./a.out(_Z17clean_exit_on_sigi+0x1c)[0x41deaa]
/lib64/libc.so.6(+0x32920)[0x593a920]
/usr/lib64/libstdc++.so.6(+0x7eb29)[0x51e6b29]
/usr/lib64/libstdc++.so.6(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE15_M_insert_floatIdEES3_S3_RSt8ios_baseccT_+0xd3)[0x51e8f43]
/usr/lib64/libstdc++.so.6(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecd+0x19)[0x51e9269]
/usr/lib64/libstdc++.so.6(_ZNSo9_M_insertIdEERSoT_+0x9f)[0x51fc87f]
./a.out(This line of code corresponds to the line where I try to do the conversion)

a.out is my program, and I run valgrind this way: valgrind --tool=memcheck ./a.out

Another weird thing is that when I call mc->end(); while the program runs fine (Any signal received, Object just finished his work), I don’t get segfault in any way (as is and with valgrind).

Please, don’t tell me ‘Don’t close your program with Control+C blah blah…’ this piece of code is for logging any error the program possibly have without losing data in case of segfault, killing it because of deadlock or something else.

EDIT: Maybe is a valgrind bug (I don’t know, searched on google but found nothing, don’t kill me), any workaround will be accepted too.

EDIT2: Just realized that boost calls ostream too (Here is clearer than using vim :-/), going to try sprintf float conversion.

EDIT3: Tried this sprintf(fl, "%.1g", f); but still crashes, backtrace:

./a.out(_Z17clean_exit_on_sigi+0x40)[0x41df24]
/lib64/libc.so.6(+0x32920)[0x593a920]
/lib64/libc.so.6(sprintf+0x56)[0x5956be6]
./a.out(Line where sprintf is)

Answer 1

Ok, after some hours of reading and research, I found the problem, I’m going to answer my own question because noone does, only a comment by @Kerrek SB [ https://stackoverflow.com/users/596781/kerrek-sb ] but I cannot accept a comment. (Thank you)

It’s as easy as inside a signal handler you only can call a bunch of functions safely: http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

If you call some non-async-safe functions, they can work, but not always.

If you want to call non-async-safe functions inside a signal handler, you can do this:

• Create 2 pipes. int pip1[2]; int pip2[2]; pipe(pip1); pipe(pip2);
• Create a new thread and make the thread wait to receive some data from the 1rst pipe read(pip1[0], msg, 1);
• When signal handler is called, use write async-safe function to write to the 1rst pipe write(pip1[1], "0", 1);
• Then make the signal wait for the second pipe with read(pip2[0], msg, 1);
• The thread will wake up and do all the job he has to do (saving data to database in this case), after that, make the thread write data to the second pipe write(pip2[1], "0", 1);
• Now main thread will wake up and finish with _Exit(1) or something else.

Info:

I’m using 2 pipes because if I write to a pipe and just after that I read it, it’s possible that the 2nd thread never wakes up because the main thread have read the data have just written. And I’m using a secondary pipe to block the main thread because I don’t want it to exit while the 2nd thread is saving data.

Keep in mind that signal handler maybe has been called while modifying a shared resource, if your 2nd thread acceses that resource is possible that you encounter a second segfault, so be careful when accesing shared resources with your 2nd thread (Global variables or something else).

If you are testing with valgrind and don’t want to receive ‘false’ memory leaks when receiving a signal you can do this before exiting pthread_join(2ndthread, NULL) and exit(1) instead of _Exit(1). These are non-async-safe functions, but at least you can test memory leaks and close you app with a signal without receiving ‘false’ memory leaks.

Hope this helps someone. Thanks again @Kerrek SB.