Mario Charest wrote:
>> Seg faults in libc's malloc or free routines are generally caused by the
>> application program overwriting areas of heap that it's not supposed to,
>> not by libc itself. 
> 
> In this case it is most probably cause by a bug in the C++ library and streams.  This bug shows up when using multi-
thread.  I was told this bug would not get fixed.  You need to upgrade to 6.4.X.

You report was against using Dinkumware C++ Library and Rodrigo is using 
the GNU C++ library. Separate libraries, separate issues.

Regards,

Ryan Mansfield

>> -----Original Message-----
>> From: Rodrigo Campos [mailto:community-noreply@qnx.com] 
>> Sent: Monday, August 24, 2009 12:16 PM
>> To: momentics-community
>> Subject: malloc causes segfault/SIGSEGV
>>
>> I'm using C++ in QNX 6.3.2 and I got a segmentation fault while I was
>> calling "put" on a ostream. The ostream, 
>> internally called malloc and it cause the segfault.
>>
>> Here is the backtrace from the core file:
>>
>> (gdb) bt
>> #0  0xb031ee55 in _block_mem_malloc_align () from
>> /usr/qnx632/target/qnx6/x86/lib/libc.so.2
>> #1  0xb031ef6d in _band_get_aligned () from
>> /usr/qnx632/target/qnx6/x86/lib/libc.so.2
>> #2  0xb031f01b in _band_get () from
>> /usr/qnx632/target/qnx6/x86/lib/libc.so.2
>> #3  0xb03210ec in __malloc_lock () from
>> /usr/qnx632/target/qnx6/x86/lib/libc.so.2
>> #4  0xb03211c8 in __malloc () from
>> /usr/qnx632/target/qnx6/x86/lib/libc.so.2
>> #5  0xb031ea72 in malloc () from
>> /usr/qnx632/target/qnx6/x86/lib/libc.so.2
>> #6  0xb851abef in __builtin_new () from
>> /usr/qnx632/target/qnx6/x86/lib/libcpp.so.3
>> #7  0xb851a9f3 in __builtin_vec_new () from
>> /usr/qnx632/target/qnx6/x86/lib/libcpp.so.3
>> #8  0x080556a3 in stringbuf::overflow (this=0x7e5bf04, c=0) at
>> /opt/qnx632/target/qnx6/usr/include/g++-3/sstream:110
>> #9  0xb823951d in __overflow () at
>> ../../../../libstdc++/std/std_valarray.h:268
>> #10 0xb823dbdc in _IO_putc () at
>> ../../../../libstdc++/std/std_valarray.h:268
>> #11 0xb8253d30 in ostream::put (this=0x7e5bf00, c=0) at
>> ../../../../libio/streambuf.h:395
>> #12 0x0806a8a3 in operator<< (os=@0x7e5bf00, tag=@0x809f570) at
>> rftag-analog.cc:44
>> #13 0x080636e9 in operator<< (os=@0x7e5bf00, grp=@0x80c79b8) at
>> ielgroup.cc:321
>> #14 0x0806e0b9 in IElcomConnection::handlePeriodicGroup (this=0x80be0a0)
>> at ielcomconnection.cc:558
>> #15 0x0806de6a in IElcomConnection::thread_handlePeriodicGroup
>> (arg=0x80be0a0) at ielcomconnection.cc:524
>>
>>
>> Until #12 is what my program does, after that all is inside the call to
>> "put" of the ostream (os is a ostream).
>>
>> From the back trace it seems clear that what is causing the segfault is
>> inside the malloc, so it should be a bug in 
>> QNX's libc, if I'm not missing something.
>>
>>
>> Just in case it matters, besides Apache, php, ssh and RealFlex (with
>> Ls900 driver) its a plain/default QNX 6.3.2 run-
>> time installation on x86. And this program (the one I pasted the back
>> trace) is multi-thread, and this is the thread it 
>> causes the segfault.
>>
>>
>> Also, I don't know how to reproduce it, it happened only once in almost
>> 8 months.
>>
>>
>> Does this happen to anyone (segfault in malloc) ? It's a known bug or
>> can I report it somewhere else ? Does anyone know 
>> if 6.3 is maintained yet and I can expect a new release fixing this ?
>>
>>
>>
>>
>> Thanks a lot,
>>...

There are multiple bugs in 6.3.2 that can collide when using 6.3.2
Dinkum ostreams.
1) name_detach() leaks a sync object (mutex???) into the heap.
2) ostream << mallocs memory for a mutex, registers the mutex with the
kernel, but does not check the error return of the registration. 
If that malloced memory contains one of those leaked sync objects the
registration fails and the ostream mutex is not initialized. The result
is either no thread-safe coordination, or the ostream thread remains
blocked forever on a bogus mutex that will never unblock. I don't know
whether this can lead to a segment violation, but I would think that the
"no coordination" scenario could.

The name_detach() bug has been fixed in 6.4. I was told that the ostream
non-check for an error return would not be fixed, so I assume it is
still there in 6.4.1.

Mario, are there additional streams bugs that you are aware of?


> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Monday, August 24, 2009 12:37 PM
> To: momentics-community
> Subject: Re: RE: malloc causes segfault/SIGSEGV
> 
> > Seg faults in libc's malloc or free routines are generally caused by
> the
> > application program overwriting areas of heap that it's not supposed
> to,
> > not by libc itself.
> 
> In this case it is most probably cause by a bug in the C++ library and
> streams.  This bug shows up when using multi-thread.  I was told this
> bug would not get fixed.  You need to upgrade to 6.4.X.
> 
> > -----Original Message-----
> > From: Rodrigo Campos [mailto:community-noreply@qnx.com]
> > Sent: Monday, August 24, 2009 12:16 PM
> > To: momentics-community
> > Subject: malloc causes segfault/SIGSEGV
> >
> > I'm using C++ in QNX 6.3.2 and I got a segmentation fault while I
was
> > calling "put" on a ostream. The ostream,
> > internally called malloc and it cause the segfault.
> >
> > Here is the backtrace from the core file:
> >
> > (gdb) bt
> > #0  0xb031ee55 in _block_mem_malloc_align () from
> > /usr/qnx632/target/qnx6/x86/lib/libc.so.2
> > #1  0xb031ef6d in _band_get_aligned () from
> > /usr/qnx632/target/qnx6/x86/lib/libc.so.2
> > #2  0xb031f01b in _band_get () from
> > /usr/qnx632/target/qnx6/x86/lib/libc.so.2
> > #3  0xb03210ec in __malloc_lock () from
> > /usr/qnx632/target/qnx6/x86/lib/libc.so.2
> > #4  0xb03211c8 in __malloc () from
> > /usr/qnx632/target/qnx6/x86/lib/libc.so.2
> > #5  0xb031ea72 in malloc () from
> > /usr/qnx632/target/qnx6/x86/lib/libc.so.2
> > #6  0xb851abef in __builtin_new () from
> > /usr/qnx632/target/qnx6/x86/lib/libcpp.so.3
> > #7  0xb851a9f3 in __builtin_vec_new () from
> > /usr/qnx632/target/qnx6/x86/lib/libcpp.so.3
> > #8  0x080556a3 in stringbuf::overflow (this=0x7e5bf04, c=0) at
> > /opt/qnx632/target/qnx6/usr/include/g++-3/sstream:110
> > #9  0xb823951d in __overflow () at
> > ../../../../libstdc++/std/std_valarray.h:268
> > #10 0xb823dbdc in _IO_putc () at
> > ../../../../libstdc++/std/std_valarray.h:268
> > #11 0xb8253d30 in ostream::put (this=0x7e5bf00, c=0) at
> > ../../../../libio/streambuf.h:395
> > #12 0x0806a8a3 in operator<< (os=@0x7e5bf00, tag=@0x809f570) at
> > rftag-analog.cc:44
> > #13 0x080636e9 in operator<< (os=@0x7e5bf00, grp=@0x80c79b8) at
> > ielgroup.cc:321
> > #14 0x0806e0b9 in IElcomConnection::handlePeriodicGroup
> (this=0x80be0a0)
> > at ielcomconnection.cc:558
> > #15 0x0806de6a in IElcomConnection::thread_handlePeriodicGroup
> > (arg=0x80be0a0) at ielcomconnection.cc:524
> >
> >
> > Until #12 is what my program does, after that all is inside...