Solved: SIGSEGV caught | Experts Exchange

Create Account

Questions

Followers

Top Experts

cincin77

SIGSEGV caught

Hi,

i work on a multithreaded application(linux mandrake 8.0, kernel:2.4.10) which sometimes freezes. when i look with 'gdb', i see the following:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4101 (LWP 2113)]
0x402a5ebc in memcpy () from /lib/libc.so.6
(gdb) info locals
No symbol table info available.

i think, this does not say much. i dont even know during which funtion, this signal is taken. what should i look for?
and also does this message make sure that, signal is caught during a memcpy operation?

thanks in advance.

Zero AI Policy

We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.

jimmy007

libc.so.6 is not compiled with debug information in your case. Can`t get callers and back trace. This library implement AINSI C functions like memcpy(..). It make sense to believe that the violation is related to this operation.

In this case, I add debug trace (printf). This give an idea on where and when a deadlock or wrong memory manipulation occur.

With threads, make sure that memory operation(write/read) is exclusive. Protect your code with ciritical sections or semaphore. Try to avoid cases where a thread can allocate memory and another one free it. You end up with invalid memory location.

Hope will help.

Kamots

As your error seems to be occurng within one of the ansi C library functions, a corrupted heap seems likely. I've only had this happen to me once, in my case I had freed memory twice, which was causing malloc to eventually fault. I had forgotten to set a pointer to NULL after freeing it's memory. And thus my non-NULL check before freeing later was true and heap died.

google can give more information as to possible causes of a corrupted heap. I'm not sure this is your problem, but it seems a good place to start.

Good Luck

JIEXA🇮🇱

Once you enter the gdb, write "where" to obtain a stack trace, not only the innermost function.
Possibly, you call for memcpy() with a wrong addresses (maybe null), or call to other function that calls memcpy() with wrong addresses (like printf("%s",NULL);).

So, whithout at least stack trace you can not tell anything.

EARN REWARDS FOR ASKING, ANSWERING, AND MORE.

Earn free swag for participating on the platform.

cincin77

ASKER

as i said before, there is no stack info. also although i compile, link with -g option:
mpeg: son_mpe.o mut_sent.o bgrab.o
gcc -ggdb -O2 -D_GNU_SOURCE -I/usr/local/include -O2 -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o mytest mut_sent.o son_mpe.o bgrab.o $(MYLIB)

when i try: gdb mytest core.xxxx, it hangs and does not open for some core files.

what is your recommendation for finding the source of the segmentation faults?

regards

ASKER CERTIFIED SOLUTION

JIEXA🇮🇱

membership

Signing up is free and takes 30 seconds. No credit card required.

Create Account

cincin77

ASKER

oki
thanks for all of the responses.
i found the problem.
from the comments above, the most useful was from JIEXA.

Questions

Followers

Top Experts

C is a general-purpose, imperative computer programming language, supporting structured programming, lexical variable scope and recursion, while a static type system prevents many unintended operations. By design, C provides constructs that map efficiently to typical machine instructions, so it has found lasting use in applications that had formerly been coded in assembly language, including operating systems as well as various application software for computers ranging from supercomputers to embedded systems. It is distinct from C++ (which has its roots in C) and C#, and many later languages have borrowed directly or indirectly from C.