I've a problem finishing a thread, and doing the debug with GDB I've found that I've a segmentation after invoking the function pthread_exit(NULL);
Some messages which I've are
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 12371]
0x400e9fd0 in free () from /lib/libc.so.6
Debugging with this option "gdb -c core EMBEDDED" I've got this warning message
"warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Core was generated by `/home/root/SSL/EMBEDDED'.
Program terminated with signal 11, Segmentation fault.
0 0x400e9fd0 in free () from /lib/libc.so.6"
Some advices, some suggestions are welcome, thanks.
Related
I'm trying to compile my homework and I needed to recreate strlwr() (only available on Windows), and I'm getting this error:
Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
I'm using this strlwr().
I found the code for strlen-avx2.S, but I can't find it in my system.
If I use this one, there's no mention of strlen-avx2.S, but still getting segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
0x000055555555532d in strlwr (str=0x0) at parser.c:36
36 while (*p) {
I am using gdb to find out why I am getting a seg fault. I run the command gba myProg core so I can see the core dump from the seg fault. The core dump reads as follows.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __GI__IO_fwrite (buf=0x7f32040167a0, size=1, count=2, fp=0x0) at iofwrite.c:37
37 iofwrite.c: No such file or directory.
[Current thread is 1 (Thread 0x7f3209bac700 (LWP 20157))]
I'm having a hard time figuring out the error message. It seems to be saying that the seg fault is due to iofwrite.c but I can't seem to find any information on such a file. I assume it relates to fwrite.
You are passing a NULL fp to fwrite(). It's impossible to answer more completely without code.
I had encounted this question too, the reason was my output file name is invalid.
I know this question has been asked before, but I have read all the threads and I didn't find an answer.
From the moment I execure run to start debugging my project, I get this : Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6]. When I do ctrl+c, gdb tells me : Program received signal SIGINT, Interrupt.
0x00000000 in ?? ()
Usually it'll tell me which file and which function it got interrupted at not 0x00000000 in ?? ()
GDB no longer hits breakpoints, and what makes matter crazier is the fact that a colleague and I, are sharing the same session (the debug is done using cygwin with a remote machine) and it works fine for them but not for me.
when I try to get info about the threads using info threads here's what I get :
[New Thread 20]
[New Thread 21]
[New Thread 22]
Id Target Id Frame
4 Thread 22 (ssp=0xa9004d5c) 0x00000000 in ?? ()
3 Thread 21 (ssp=0xa9002e64) 0x00000010 in ?? ()
2 Thread 20 (ssp=0xa9000ef4) 0x00000000 in ?? ()
The current thread <Thread ID 1> has terminated. See `help thread'
there's no thread 6, there's no * to indicate which thread gdb is using. And I don't even know if that's linked to the problem.
Can anyone please help me?
You are not providing nearly enough info to help you. Details matter, and you are withholding them. Versions of GDB and gdbserver matter, how you invoke GDB and gdbserver matter, what warnings you receive from GDB (if any) matter.
Now, this error message:
Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6]
usually means that gdbserver has not attached one of the threads of your process, and that thread has tried to execute breakpoint instruction (you do have breakpoints set before this happens, don't you?).
One of the reasons this may happen is when your GDB loads "wrong" libthread_db.so (one that doesn't match the target libc.so.6).
what makes matter crazier is the fact that a colleague and I, are sharing the same session (the debug is done using cygwin with a remote machine) and it works fine for them but not for me.
I am not sure what you mean by "same session", but it's probably not "when he types commands, they work; but when I type the same commands into the same GDB, they don't".
One difference between you and your colleague could be LD_LIBRATY_PATH environment variable setting. Another could be in ~/.gdbinit or in ./.gdbinit.
I suggest running gdb -nx to get rid of the latter, and unsetting LD_LIBRARY_PATH to get rid of the former.
The problem with the whole thing and for some reason no one seemed to notice it is this :
this is how I call gdb /usr/local/build/gdbx.y/gdb/gdb what I should be doing is this : /usr/local/build/gdbx.y/build/gdb/gdb
It was a path problem.
My program (it is an smtp server program, tested by jmeter) run without any problem when it is run by valgrind.
But failed (got SIGABRT) finally, if it is running without valgrind or run within 'gdb' debugger.
I've tested all of the valgrind's tools (memcheck,helgrind,drd,massif) but no one reported any problem. I haven't found any memory leaks (checked by mtrace() ).
I've got the following :
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7101b70 (LWP 1639)]
0xb776d416 in __kernel_vsyscall ()
the backtrace show various locations which changend run by run. The problems always allude to malloc() or free() (and always correlate with a string (char array) )
The question is: how can I found the problem, if valgrind and mtrace did not show any problem and the program can run without stoppage (within valgrind) in an endless jmeter test loop?
I am teaching myself to use gdb and am running some random tests. It may be worth mentioning that I am using a portable installation of MinGW on Windows 7 x64. I've created a program which I know results in a stack overflow, and as I run through it in gdb I first get two SIGSEGV signals (no surprise), and then it exits (again no surprise) with code 030000000375.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program exited with code 030000000375.
Curiosity getting the best of me... what the heck is that code? I googled it and found very little.
Thanks!
UPDATE: For reference I tried the same program on Ubuntu, and the results are slightly different:
Program received signal SIGSEGV, Segmentation fault.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
gdb prints out the exit code in octal format. Not obvious, but indicated by the leading 0.
So 030000000375 is 0xC00000FD in hex, which makes the code look much more common to a windows programmer.
0xC00000FD is STATUS_STACK_OVERFLOW and should be defined in ntstatus.h.