Help -- segmentation fault

[Allen Zhao]

I am working on a project which call  'malloc' and 'new' command many times in more then two threads. Most of the time the program crashed with 'segmentation fault" message. Some times it crashed with the following messages:

 

signal fault in critical section
signal number: 11, signal code: 1,                          fault address: 0x5, pc: 0xff13ba8c, sp: 0xfdd017d0
libthread panic: fault in libthread critical section (PID: 7519 LWP 5)
stacktrace:
        ff1299f0
        ff12991c
        45a38
        3b218
        2e1ec
        ff13b824
        2da54
signal number: 11, signal code: 1,                          fault address: 0x5, pc: 0xff13ba8c, sp: 0xfe1097d0
libthread panic: fault in libthread critical section (PID: 7543 LWP 4)
stacktrace:
        ff1299f0
        ff12991c
        45a38
        3b218
        2e1ec
        ff13b824
        2da54
1;P;chstats;chicago;1;020816140843;washington;0;0
signal fault in critical section
signal number: 11, signal code: 1,                          fault address: 0x5, pc: 0xff13ba8c, sp: 0xfdf057d0
libthread panic: fault in libthread critical section (PID: 7535 LWP 1)
stacktrace:
        ff1299f0
        ff12991c
        45a38
        3b218
        2e1ec
        ff13b824
        2da54

Could someone give me help on this? Thanks.

[Barry Margolin]

In article <Elb79.28407$8aG1....@news01.bloor.is.net.cable.rogers.com>,

Allen Zhao <qz...@rogers.com> wrote:
>I am working on a project which call 'malloc' and 'new' command many
>times in more then two threads. Most of the time the program crashed with
>'segmentation fault" message. Some times it crashed with the following
>messages:

As I said when you posted this in comp.protocols.tcp-ip, you need to post
some code to give us a fighting chance at figuring out what you're doing
wrong. Otherwise we're just guessing.

You also need to tell us what operating system you're using.

P.S. Please don't post HTML.

--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[Tomasz Jaworski]

He's probably writting to a null pointer :)

Tomasz.

"Barry Margolin" <bar...@genuity.net> wrote in message
news:AFb79.21$%k.3...@paloalto-snr1.gtei.net...

[Fletcher Glenn]

More likely, he's re-entering malloc or new. Or committing
any of the other allocation sins that trash the heap.

--
Fletcher Glenn
email f-g-l...@quest.com (remove the dashes)

[peter]

Uninitialized pointers also give simular results, though may produce hard
to trace data corruption. I've also seen this message when freeing NULL,
though that would be library dependent.

[E. Gibbons]

In article <3D5D6338...@nospam.calweb.com>,

peter <pe...@nospam.calweb.com> wrote:
>>
>Uninitialized pointers also give simular results, though may produce hard
>to trace data corruption. I've also seen this message when freeing NULL,
>though that would be library dependent.

Hopefully, the only dependency there would come up if the library does
not claim to be a conforming standard C library: free(NULL) should be
perfectly alright in ANSI C, a harmless no-op. Assuming the right
#includes, etc., of course.

--Ben

--

[Toni Schlichting]

If you don't want to provide us with the code related to the problem,
chances are zero that you get sufficient answers. Try debugging ;-) This
very often solves problems like this.

libthread has no chance if you provide it with a ptr pointing to the
outback. If you don't now where this happens in your code first try to
analyse the log or first place some log statement in your code:

C++ and C Debugging, Testing, and Reliability (David A. Spuler)

Then start debugging. If you still don't find the bug, post the question
with the code sample where you believe the error is located.

Ciao, Toni

[Allen Zhao]

Thanks, everyone. I found the problem. It happened here.

Message* Multi_Queue::get_i (int level)
{
Message* retn;
QueuedMessage * q = queueAnchors[level];
retn = q->data;
queueAnchors[level] = q->next;
if(q == queueTails[level])
queueTails[level] = NULL;
if(full_i())
{
pthread_cond_signal(& not_full);
}
message_count--;
delete q; //no problem when retn was read and used later, but caused core
dump a long time later

return retn;
}

"Allen Zhao" <qz...@rogers.com> wrote in message
news:Elb79.28407$8aG1....@news01.bloor.is.net.cable.rogers.com...

[peter]

Memory burp, realloc NULL. Saw it using Cygwin.

[Floyd Davidson]

peter <pe...@nospam.calweb.com> wrote:

>E. Gibbons wrote:
>> peter <pe...@nospam.calweb.com> wrote:
>>
>>>Uninitialized pointers also give simular results, though may produce hard
>>>to trace data corruption. I've also seen this message when freeing NULL,
>>>though that would be library dependent.
>>
>>
>> Hopefully, the only dependency there would come up if the library does
>> not claim to be a conforming standard C library: free(NULL) should be
>> perfectly alright in ANSI C, a harmless no-op. Assuming the right
>> #includes, etc., of course.
>>
>> --Ben
>>
>
>Memory burp, realloc NULL. Saw it using Cygwin.

Man pages are wonderful things. For example... the man page
for realloc() is the same for free() (and also covers malloc() and
calloc() too. Reading it would have provided these two tidbits,

free() frees the memory space pointed to by ptr... If
ptr is NULL, no opera- tion is performed.

realloc() changes the size of the memory block pointed to
by ptr to size bytes. ... If ptr is NULL, the call is
equivalent to malloc(size); ...

--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com