I have created a c code for a real-time project. I'm using an Ubuntu 15.04 and the code crash with this result(gdb):
Program received signal SIGSEGV , Segmentation fault.
[Switching to thread 0x7fffeb7fe700 (LWP 4072)]
__GI___pthread_mutex_lock (mutex=0xfffffffeb5c6dcb0)
at ../nptl/pthread_mutex_loxk.c:67
67 ../nptl/pthread_mutex_lock.c: File o directory non esistente
Tiping :
(gdb) x/i $pc the following message appear on the screen:
=> 0x7ffff7bc4c84 <__GI___pthread_mutex_lock+4>: move 0x10(%rdi),%edx
Can the problem be caused by stackoverflow? How can I solve the problem?
Is it possible to know the exact code's row in which the crash appear?
I'd suggest using Valgrind to help trace these kind of errors. Also, be sure to pass the -g option to gcc so that line numbers and source lines show up when you're debugging.
Related
I am getting some undefined behavior in my code causing segmentation fault. But when i built it with -fsanitize=address , they were handled well and not throwing any segmentation faults. Came to know that AddressSanitizer has changed their behavior (buffer overruns, leaks etc) and executing the program successfully.
gcc -g -o scrmenu -fsanitize=address -D_FORTIFY_SOURCE=2 caomenu.c superbox.c -L/opt/oracle/product/19c/dbhome_1/lib -L/usr/include/ -L/usr/lib64/ -lclntsh -lcurses
But i want to know the actual errors/undefined behaviors in my code. so to get those error reports i have set the option -D_FORTIFY_SOURCE=2 after reading it in some blog thread post. But it is indicating a fatal error but not providing exact error details. instead it's throwing below errors which is not leaving any clue.
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 696460]
[Detaching after fork from child process 696460]
==696450==LeakSanitizer has encountered a fatal error.
==696450==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==696450==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
[Inferior 1 (process 696450) exited with code 01]
Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-189.5.0.1.el8_6.x86_64 libasan-8.5.0-16.0.1.el8_7.x86_64 libgcc-8.5.0-16.0.1.el8_7.x86_64 libnsl-2.28-189.5.0.1.el8_6.x86_64 libstdc++-8.5.0-15.0.2.el8.x86_64 ncurses-libs-6.1-9.20180224.el8.x86_64 numactl-libs-2.0.12-13.el8.x86_64 sssd-client-2.7.3-4.0.1.el8_7.1.x86_64
definitely Addresssinitizer is detecting desired run time errors. Is there any way that i could see the details of them?
We're learning to use GDB in my Computer Architecture class. To do this we do most of our work by using SSH to connect to a raspberry pi. When running GDB on some code he gave us to debug though it ends with an error message on how it can't find raise.c
I've tried:
installing libc6, libc6-dbg (says they're already up-to-date)
apt-get source glibc (gives me: "You must put some 'source' URIs in your sources.list")
https://stackoverflow.com/a/48287761/12015458 (apt source returns same thing as the apt-get source above, the "find $PWD" command the user gave returns nothing)
I've tried looking for it manually where told it may be? (/lib/libc doesn't exist for me)
This is the code he gave us to try debugging on GDB:
#include <stdio.h>
main()
{
int x,y;
y=54389;
for (x=10; x>=0; x--)
y=y/x;
printf("%d\n",y);
}
However, whenever I run the code in GDB I get the following error:
Program received signal SIGFPE, Arithmetic exception.
__GI_raise (sig=8) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
I asked him about it and he didn't really have any ideas on how to fix it.
It does not really matter that the source for raise() is not found. It would only show you the line where the exception is finally raised, but not the place where the error is triggered.
Run the erroneous program again in GDB. And when the exception is raised, investigate the call stack and the stackframes with GBDs commands. This is the point in your task, so I won't give you more than this hint.
If you're clever you can see the error in the given source just by looking at it. ;-)
When GDB does not know any symbol, you need to compile with the option -g to get debugger support.
EDIT
Now on a Windows system this is my log (please excuse the colouring, I didn't found a language selector for pure text):
D:\tmp\StackOverflow\so_027 > type crash1.c
#include <stdio.h>
main()
{
int x,y;
y=54389;
for (x=10; x>=0; x--)
y=y/x;
printf("%d\n",y);
}
D:\tmp\StackOverflow\so_027 > gcc crash1.c -g -o crash1.out
crash1.c:2:1: warning: return type defaults to 'int' [-Wimplicit-int]
main()
^~~~
D:\tmp\StackOverflow\so_027 > dir
[...cut...]
04.09.2019 08:33 144 crash1.c
04.09.2019 08:40 54.716 crash1.out
D:\tmp\StackOverflow\so_027 > gdb crash1.out
GNU gdb (GDB) 8.1
[...cut...]
This GDB was configured as "x86_64-w64-mingw32".
[...cut...]
Reading symbols from crash1.out...done.
(gdb) run
Starting program: D:\tmp\StackOverflow\so_027\crash1.out
[New Thread 4520.0x28b8]
[New Thread 4520.0x33f0]
Thread 1 received signal SIGFPE, Arithmetic exception.
0x0000000000401571 in main () at crash1.c:7
7 y=y/x;
(gdb) backtrace
#0 0x0000000000401571 in main () at crash1.c:7
(gdb) help stack
Examining the stack.
The stack is made up of stack frames. Gdb assigns numbers to stack frames
counting from zero for the innermost (currently executing) frame.
At any time gdb identifies one frame as the "selected" frame.
Variable lookups are done with respect to the selected frame.
When the program being debugged stops, gdb selects the innermost frame.
The commands below can be used to select other frames by number or address.
List of commands:
backtrace -- Print backtrace of all stack frames
bt -- Print backtrace of all stack frames
down -- Select and print stack frame called by this one
frame -- Select and print a stack frame
return -- Make selected stack frame return to its caller
select-frame -- Select a stack frame without printing anything
up -- Select and print stack frame that called this one
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) next
Thread 1 received signal SIGFPE, Arithmetic exception.
0x0000000000401571 in main () at crash1.c:7
7 y=y/x;
(gdb) next
[Inferior 1 (process 4520) exited with code 030000000224]
(gdb) next
The program is not being run.
(gdb) quit
D:\tmp\StackOverflow\so_027 >
Well, it marks directly the erroneous source line. That is different to your environment as you use a Raspi. However, it shows you some GDB commands to try.
Concerning your video:
It is clear that inside raise() you can't access x. That's why GDB moans about it.
If an exception is raised usually the program is about to quit. So there is no value in stepping forward.
Instead, as shown in my log, use GDB commands to investigate the stack frames. I think this is the issue you are about to learn.
BTW, do you know that you should be able to copy the screen content? This will make reading so much easier for us.
From a practical standpoint the other answer is correct, but if you do want the libc sources:
apt-get source is the right way to get the sources of libc, but yes, you do need to have source repositories configured in /etc/apt/sources.list.
If you're using Ubuntu, see the deb-src lines in https://help.ubuntu.com/community/Repositories/CommandLine
For debian, see https://wiki.debian.org/SourcesList#Example_sources.list
Then apt-get source should work. Remember to tell GDB where those sources are using the "directory" command.
I am trying to build a custom machine in QEMU for STM32 machine and I have written a simple code to add the machine to the QEMU -machine help list. I have also written a code where I can add all peripherals (general file /main file)
But when I run the code I get Segmentation fault (core dumped) error. When I commented some part , I could pinpoint where I was getting the error:
static Property stm32f407_soc_properties[] = {
DEFINE_PROP_STRING("cpu-type", struct stm32f407_soc,cpu_type),
DEFINE_PROP_END_OF_LIST(),
};
I was getting the error when I fetch the CPU-type. Further when I debugged through GDB, it gave some information as below which I do not understand :
(gdb) run -machine stm32f407ve_scu -kernel test.elf
Starting program: /usr/local/bin/qemu-system-arm -machine stm32f407ve_scu -kernel test.elf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe7e4f700 (LWP 3487)]
[New Thread 0x7fffe764e700 (LWP 3490)]
[New Thread 0x7fffe69dc700 (LWP 3500)]
[New Thread 0x7fffe61db700 (LWP 3501)]
Thread 1 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
0x00005555557ea571 in cpu_get_address_space (cpu=0x0, asidx=1) at /home/sups/Documents/stm32/qemu/exec.c:930
930 return cpu->cpu_ases[asidx].as;
(gdb) where
#0 0x00005555557ea571 in cpu_get_address_space (cpu=0x0, asidx=1) at /home/sups/Documents/stm32/qemu/exec.c:930
#1 0x00005555559700c6 in armv7m_load_kernel (cpu=0x0, kernel_filename=0x5555568afa00 "test.elf", mem_size=2097152)
at /home/sups/Documents/stm32/qemu/hw/arm/armv7m.c:297
#2 0x0000555555999e3e in stm32f407ve_scu_init (machine=0x555556783f00) at /home/sups/Documents/stm32/qemu/hw/arm/stm32f407ve_scu.c:57
#3 0x0000555555ae9ed9 in machine_run_board_init (machine=0x555556783f00) at hw/core/machine.c:830
#4 0x0000555555a40372 in main (argc=5, argv=0x7fffffffde98, envp=0x7fffffffdec8) at vl.c:4516
I opened all the files mentioned in the errors above and checked what line the errors are and all these lines correspond to machine calls. But I do not know what should I be changing?
Can someone help me?
Thank you.
I'm trying to complete a tutorial about exploiting a buffer overflow, https://www.youtube.com/watch?v=hJ8IwyhqzD4. Everything seems to work, except at the end, the '/bin/sh' program isn't run, though I can see the no-op symbols and '/bin/sh' text.
The message should read "Process is executing new program: /bin/sh", but instead I get:
Program received signal SIGILL, Illegal instruction.
0xb7e30a00 in __libc_start_main (main=0x804844d <main>, argc=3,
argv=0xbffff0a4, init=0x8048490 <__libc_csu_init>,
fini=0x8048500 <__libc_csu_fini>, rtld_fini=0xb7fed180 <_dl_fini>,
stack_end=0xbffff09c) at libc-start.c:246
246 libc-start.c: No such file or directory.
I also get this same message when trying to find the edge of the buffer with this command in gdb:
run $(python -c "print('A'*268)").
Any help understanding this error is greatly appreciated.
Michael
i'm trying to debug a C program, which runs on an ARM926EJ-S rev 5 (v5l). The software was cross-compiled (and is statically linked) with the std. arm-linux-gnueabi compiler (intalled via synaptic). I run Ubuntu 13.04 64bit. On the device is a Busybox v1.18.2. I successfully compiled gdbserver (with host=arm-linux-gnueabi) and gdb (with target=arm-linux-gnueabi) and can start my program on the embedded device via the locally running gdb...
My problem now is, that i don't have a proper backtrace output.
Message of gdb:
Remote debugging using 192.168.21.127:2345
0x0000a79c in ?? ()
(gdb) run
The "remote" target does not support "run". Try "help target" or "continue".
(gdb) continue
Continuing.
Cannot access memory at address 0x0
Program received signal SIGINT, Interrupt.
0x00026628 in ?? ()
(gdb) backtrace
#0 0x00026628 in ?? ()
#1 0x00036204 in ?? ()
#2 0x00036204 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
I try to compile the software with -g, -g3 -gdwarf-2, -ggdb, -ggdb3 without any difference.
Has anybody an idea what i am missing here?
Is this a problem maybe with the BusyBox or do i need additional libs on my host system?
I also tried the function backtrace_symbols from execinfo.h with nearly the same output...
Thanks in advance for any reply.
Another way for debugging is use gdb inside board follow below steps.
1)Run gdb process and attach your process to gdb using attach <pid> command
2)Continue your process using c command in gdb
Whenever you find any SIGINT or SIGSEGV then refer stack of your process using bt command in gdb.