This is annoying. I have the kernel built with debugging, kgdb over serial, and it works fine for normal debugging. But when an oops occurs it doesnt break into the debugger if it is running or allow me to start the debugger and examine the oops. This is particularly annoying as staticly declared functions dont show up in the oops stack trace making it hard to know exactly what code was called.
BTW this is running on an ARM 11 chip.
Anyone else seen this or know of a way to get it working?
Thanks in advance.
Related
I am trying to understand how the PE works under windows and so am going down the route of writing a packer.
So I took the address of entry point, that points to _mainCRTStartup and replaced it with a value that points to a "jmp _mainCRTStartup".
When I run it under a debugger my program runs fine but if I just launch the executable without a debugger it crashes and I am unable to attach a debugger post crash, the debugger says that it failed to attach to the crashing process.
I guess my questions would be: Should my approach work? If so what can I try to fix this issue?
Thanks,
Max
It turns out everything worked fine, I forgot to handle an exception in an anti-debug routine that would crash the exe if it wasn't ran in a debugger.
I have I/O Kit driver: virtual ethernet device. After some period of work OS hangs, so looks like I have some deadlock in my driver.
I've done next steps:
- connect two macbooks via FireWire
- set up debugging environment
- initialise NMI (via power button)
- connect to the target via gdb
- grab address of my kext
- create and load symbols (this is the last point in all docs I've read)
So far so good. In case of kernel panic it would be enough. But in my case there is no kernel panic and I reside in the thread that handle the NMI.
Now the question: how can I switch to the thread of my kext?
Command showalltasks gives me listing of all tasks, the only task where my kext may be running is kernel_task, so I'm trying to examine this task via showtaskthreads and showtaskstacks but can't find anything similar to my code. Am I missing something?
I would be appreciated for any suggestions or links to the docs.
I'm not answering your question directly - but would it be possible to hit your kext code with a breakpoint? A common method of kernel debugging is to nmi the machine, attach the debugger, put a breakpoint in the code of interest, resume execution (continue) and then do whatever is needed to hit the breakpoint.
Well, I'm answering my own question.
To see the thread using code of my kext I need to switch to the process using my kext. In my case it will be probably a browser (since my kext is the NKE).
But in fact it didn't help me a lot. But old print method helped me to find the deadlock. So my advice is next: for the kernel panic - use debugger, for the deadlock - use printing, find place where lock is and analyse code.
Before some time i coded my own little db editor program, i was coding it from the zero using Win API's so its not very small project.
It was working fine on all OS till now, i have Win 7 x64 with all latest updates and my application is crashing with 0xC000005 exception because of some of the Heap functions(HeapAlloc or HeapFree, i use nothing else), i tried replacing HeapAlloc & HeapFree with VirtualAlloc and VirtualFree and it was all fine, but i dont want to use the virtual memory....
Something else, i tried to attach with debugger to trace the problem, but when i attach debugger its not crashing, then i tried to display MessageBox to trace where it crashes, but when i display MessageBox its not crashing too....
My application is running as 32bit process.
Coded in C.
Anyone had similar problem ?
Firstly, both HeapAlloc and VirtualAlloc allocate virtual memory.
My guess as to what is happening is that you are writing past the boundary of the allocated memory. The reason why this does not work with HeapAlloc is that it allocates exactly the amount of memory you request. With VirtualAlloc, the size returned is the requested size rounded up to the next page boundary. In your case, this gave a bit more leeway (even though your code is still doing the wrong thing).
In terms of why it has been working so far: you just got lucky. Look carefully at the code accessing the allocated memory and if you get stuck, post the relevant part up here. If the debugger isn't helping and the bug is easily reproducible, just comment out parts of the code until you locate the line causing the crash.
Have you attached it to Debug version of your application? If the problem does not appear in debug version then you should check what warnings (on highest level) generate your code, maybe you will find some uninitialized variables. If nothing here, then you might use some static analysis tool to help with finding bugs - like PVS-Studio http://www.viva64.com/.
You can also compile Release version with debugging information enabled, this way when problem arrises you should be able to attach to your application with debugger and see callstack with function names. To make it easier to debug, disable code optimizations.
You can also try gflags from windows debugger tools, this program will trigger breakpoint each time you write outside of buffer boundary. This is really helpfull tool because not all buffer overruns end up with exceptions. Use it on application with debugging information enabled, and preferably with code optimizations off. To enable gflags for your app use:
gflags /p /enable myapp.exe /full
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff543097%28v=vs.85%29.aspx)
I'm working on writing an OS and I'm running into problems trying to debug my code. I'm using GDB to connect to Bochs' GDB stub to "remotely" debug my kernel. Connecting works fine, as does loading debugging symbols from the kernel file. I set a breakpoint for the kmain function, which is successfully located, and the debugger breaks correctly (inside my kernel). However, I can't "step" or "next" through my code, nor can GDB apparently determine which line of code is the current line.
When I try to "step", I get the following message: "Cannot find bounds of current function". This is the only error message I get at any point.
My code is being compiled in GCC with the -g flag (I've tried other types of debugging information using GCC options; none have worked.) I have tried looking through the GDB manual , as well as searching for the answer, and I'm totally stumped. Any help would be amazing.
Thanks!
Well, I got debugging working, but I had to switch emulators. I was able to get GDB working with Qemu, even though I also had problems doing that. To get GDB to connect to the Qemu gdbserver, I had to pass the following option to Qemu: "-gdb tcp::1234,ipv4". Took me forever to figure that out... Debugging works perfectly now!
Googling throws up "This is because when you attached to gdbserver, the process under
debug has not completed the C start-up code" http://www.cygwin.com/ml/gdb/2005-03/msg00237.html... http://www.bravegnu.org/gnu-eprog/c-startup.html describes the process for when you are coding for embedded devices, maybe this will help?
If you find the answer please post here as I'd like to know what the solution to the problem is too.
I don't know why but bochs with gdb-stub enabled seems to be picky with the config options. On some system following options will break it:
--enable-x86-64, --enable-vmx
I'm just getting started learning FreeScale DSCs (MC56F800x series). I've done some work with AVRs using both AVR Studio on Windows and Eclipse and avr-gcc on Linux. CodeWarrior is just not as intuitive.
Right now I'm stuck trying to debug a simple program. I start the debugger using the built-in simulator, but it never reaches the first line of main(). Instead it seems to get stuck in some initialization code (MC56F8006_init.asm), specifically this line:
;; Loop until OCCS_STAT[LCK0] = 1
wait_for_lock:
brclr #OCCS_STAT_LCK0,x:>OCCS_STAT,wait_for_lock
I've let it run for quite a while and it never gets past this. It's obviously waiting for something, but what? You would think the simulator would just work... argh. Maybe there's some options I can change to make it pass this step?
I'm going to keep digging and will post an answer here if I find it first.
Updates:
Here's what I've found:
OCCS
On Chip Clock Synthesis
brclr
Branch if Bits Clear
The instruction loops until OCCS_STAT LCK0 is set. This register means the on-chip oscillator's PLL has locked (waits for clock stabilization).
I'm still not sure why the simulator spins forever on this line, and how I can solve this without resorting to hacking up the init code (which is part of the code library and not within my project).
I am not familiar with the part or the simulator, but it seems likely that the simulator is instruction-set-only and does not simulate the PLL hardware.
In most embedded development systems, the run-time startup code is provided as source and you could modify it (or rather make a local copy in your project and assemble and link that to override the default start-up). Alternately you could simply place a breakpoint in this loop, and advance the program-counter register to get it out of the loop. In many debuggers it is possible to attach a script to a breakpoint to do this automatically.