I am learning os kernel development and still at a very beginner level. I have written a bit of code for 80386 processor and testing it on qemu using gdb as a debugger (remote debugging).
Now, strange error is coming :- When , I run the code in qemu, it runs fine but when I run it and connect it to gdb. gdb shows segmentation fault in it at a line.
My, question is that how can segmentation fault come in the os kernel when I am running in real mode currently and haven't even used memory protection. Also, if there is a mechanism by which segmentation fault is generated why is the kernel running fine in qemu.
The seg fault is thrown by the hardware not the OS. So yes you can still get segfaults, but segfaults are some of the easier bugs to fix.
Related
I am currently working with ncurses.h on my MacBook.
On there, everything runs fine. I now wanted to test it on my linux laptop.
When the program tries to creat the thread, it crashes.
I do it like this:
pthread_create(&draw_thread,NULL,draw_thread_func,NULL);
pthread_detach(draw_thread);
I have no idea why its crashing on linux, since its working on my macbook
I expect it to not crash
I have a C application which is compiled to run on redhat linux architecture, which runs just fine during normal execution. However, as soon as I start trying to debug it using GDB, it crashes: Child terminated with signal = 0xb (SIGSEGV).
The thing is that there are some caveats here - it is a linux application, but I am debugging remotely using gdbserver from a windows machine. I followed the steps in this article: https://www.linux.com/news/remote-cross-target-debugging-gdb-and-gdbserver, which basically state that I need to compile a cross-platform version of GDB that will run on Windows but can debug Linux applications. I have done this. The application is running inside a docker container on my local machine at which point I have run gdbserver on the container. I have created the cross-platform GDB executable and I am running it, connecting to the gdbserver on the docker container.
It can attach the breakpoints meaning it is finding the symbols just fine, yet as soon as the application starts doing anything, it crashes due to segfault.
The thing here is that I know it's somehow related to the cross-platform-ness of the GDB executable. If I run the regular GDB from the Windows Subsystem for Linux and connect to the gdbserver using that, it works just fine, yet the cross-platform compiled GDB causes segfaults. So, does anyone have any clues about what I might be able to do about this?
The whole point of doing this is to be able to debug using an IDE (preferably VSCode) which is why I need to use the cross-platform GDB executable and can't just use the Windows Subsystem for Linux GDB.
Any help would be greatly appreciated.
Typically when analyzing a core dump in gdb it'll print the reason why it was generated:
Core was generated by `executable'.
Program terminated with signal 11, Segmentation fault.
However I've encountered a situation where gdb isn't giving a reason:
Core was generated by `executable'.
I'm wondering what could cause a core dump where gdb doesn't give the reason for its generation.
It turns out that this core file was generated using gcore, so there wasn't actually a problem with the executable. /facepalm
I have a program with concurrency, and when I run it normally, everything works fine. However, when using valgrind, I run into (probably deadlock) issues, most likely because valgrind causes the program to run much slower. I tried debugging the program using gdb, but again I couldn't reproduce the error. I was wondering if there was some way to make gdb run slower so that I could potentially reproduce and find the bug. The program is run on a remote server.
The program is huge with loads of concurrency, so pure code analysis isn't very realistic at this point.
when using valgrind, I run into (probably deadlock) issues,
There is a way to analyze your problem when it happens while running your program under valgrind. Use gdbserver feature in valgrind in order to analyze this deadlock. Run you program under valgrind, get a deadlock, then attach gdb and investigate your deadlock. This is from valgrind doc:
A program running under Valgrind is not executed directly by the CPU.
Instead it runs on a synthetic CPU provided by Valgrind. This is why a
debugger cannot debug your program when it runs on Valgrind.
This section describes how GDB can interact with the Valgrind
gdbserver to provide a fully debuggable program under Valgrind.
So you need to run your program under valgrind in this way:
valgrind --vgdb=yes --vgdb-error=0 prog
And as soon as you get a deadlock, attach to it under gdb according to instructions here: http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver.
I think if you have indeed a deadlock, then you need to run thread apply all backtrace in gdb then.
You could try to use the helgrind valgrind plugin. It is a thread-error detector and can help you to discover inconsistent lock ordering (source of deadlocks).
Another way to do this is to place sleep call inside the source code of your critical sections. But it's a little dirty.
Another way to run gdb and valgrind simultaneously, suggested by valgrind at startup, though I didn't notice it at first:
==16218== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==16218== /path/to/gdb ./ha3_qdqx.exe
==16218== and then give GDB the following command
==16218== target remote | /path/to/valgrind/bin/vgdb --pid=16218
==16218== --pid is optional if only one valgrind process is running
I have a large program in C that compiles fine, but when I run it (./a.out) I get: Bus error 10!
I used the gdb debugger to trace the memory error but the strange thing is that the program completes normally inside the gdb..Can this behaviour somehow be explained and how am I gonna debug my code now?
On some operating systems gdb will load the program differently in gdb. I know that on MacOS gdb will disable some address space layout randomization which changes how relocation of shared libraries is done. On some operating systems gdb will load more sections than a normal program execution or load those sections with wider permissions (non-executable memory might be executable under gdb or read-only will become writeable).
Your best bet is to catch a core dump of the problem and continue debugging from there. Valgrind is also good at catching this type of bugs.