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
Related
I am learning how to write some code in the Linux kernel, and i would like to start practicing writing code in the kernel, but my question is what is the process of building and running the modified kernel?
should I just each time, when I modify the kernel code, to recompile the kernel, reinstall it on my machine and then reboot my machine, or is there another way of doing this process in the real life, in the industry?
Well, easiest is if you can have the code you're modifying in a module, then you can remove the old version and load in the new version.
Alternatively, you could run the kernel in a virtual machine inside your host computer! That way you need to only reboot the virtual machine, not the entire physical computer.
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.
I have NetBSD5.1 source. I have compiled the kernel and userland with the source. When I native compile a sample C program with pthread_create() in ARM NetBSD5.1, it is crashing. Same program is running successfuly in my Linux PC. Want to know if Pthread is supported in ARM machine which run NetBSD5.1 OS?
Note: other sample C programs native compiled in ARM machine runs successfully.
It should work, I think. (I don't have an ARM system running 5.1 at the moment -- mine are running a pre-7.0 -current.)
If you can show some more details about the crash, e.g. stack backtraces from the debugger, then perhaps I or someone else can provide more help.
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.
I'm trying to debug a simple cross-platform commandline program (a C parser, itself written in C) and running into something strange.
On Windows, when I run it on a small dataset (the source code of glib) it completes successfully, and when I run it on a large dataset (the source code of the Linux kernel) it exits with an out of memory error. I'm not sure whether the latter is a bug in my code or just a consequence of not just having optimized the memory consumption yet, so I've been trying to run it on Linux so I can get some feedback from valgrind.
On Linux (Ubuntu 11.04 x64 in VirtualBox), when I run my program on a small dataset it completes successfully, and when I run it on a large dataset Linux locks up hard enough I have to reset the entire virtual box (mouse pointer still moves but other than that it's completely unresponsive; Windows task manager says the virtual box is using one hundred percent of a CPU core but not allocating memory).
I wouldn't have expected a bug in my code to crash Linux unless I was writing something like a device driver, and when I try simple test cases that allocate too much memory, go into an infinite loop or both, Linux can handle them just fine. What kind of bug should I be looking for, or what am I missing?
On Linux (Ubuntu 11.04 x64 in VirtualBox)
Probably you haven't reserved enough memory to your virtual machine.
This is most likely an infinite loop (easily done in a parser), which could easily take up 100% cpu or 100% ram.
Attach a debugger!
e.g. gdb
http://www.gnu.org/s/gdb/
gdb comes with gcc on Ubuntu etc...
Here's a how-to: http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html
EDIT: just saw you already tried gdb. So, try running strace on it, it might give you a hint.
Further to that, try adding log messages to see how far the program gets (primitive, but it'll work eventually!)