I'm trying to debug a gtk program by attaching it to gdb debugger but when I did the, gtk app freeze unless I execute next instruction or continue the program. It's annoying. I tried using ltrace but it is fill with gtk functions. How am I gonna debug this?
Related
I'm using GDB (through an IDE) to debug an arm cortex microcontroller, and I've encountered an issue where the micro is halted briefly (for 10-20ms) whenever a breakpoint is set or cleared (not hit, but set, as in the code has not yet reached the breakpoint). This long of a pause can cause significant problems when driving an electric motor, for example.
The IDE has a debug console which shows that the GDB client is sending a SIGINT to the GDB server whenever I add or remove a breakpoint. I know that in the command-line client you have to use ctrl+c to interrupt the process to issue any command, but for modern microcontrollers (ARM cortex-m, etc.) it is not necessary to interrupt the processor to insert breakpoints, read memory, and in some cases to trace program execution. I am wondering if this is something that is being imposed by the GDB interface artificially.
Is there any way to create a new breakpoint without halting the target?
I have tried using "async" mode in GDB, but it informs me that I must halt the program to insert breakpoints. I have also verified that breakpoints can be set with the underlying debug server (OpenOCD) without halting, so in this case GDB is incorrect.
Any input is appreciated, and thanks in advance.
I'm doing an exploit type challenge. The challenge's binary to exploit uses a modified version of libc.so.
So before running linux server or radare2 / ida, the export environment variable LD_PRELOAD=/path2/libc_modified.so and then I put a breakpoint at the first assembly statement of the main. With ida I cannot launch binary however I can attach to process, but the breakpoints inserted after a read are bypassed so ida cannot stop and I can't debug binary.
With radare2 I can launch binary but breakpoint inserted at first instruction of main are bypassed.
I can debug executables that doesn't use libraries to be loaded with the LD_PRELOAD and my breakpoints are catched.
Does anyone know the cause of this behavior?
I want to debug a specific process on a remote system and the only way i can do that is to use the kernel debugging method.
It works pretty good with just WINDBG, but i think ida can give me the extra edge i need for a better reversing experience.
So far debugging with windbg was successfull but now when i am using the windbg plugin in ida:
what i am actually experiencing is that i cant get the extra analysis from ida, all i can do is attach only to the process it self (only one available to attach to). and in the Modules window all i can see is the ntkrpamp.exe, which i assume is the kernel process.
i can use all WINDBG regular commands like !process 0 0, etc.. and can debug normally but nothing shows in the IDA window
I have never debugged dynamically using IDA but i can see it is possible..
could it work aswell in a kernel debugging session?
Edit:
I just noticed it is possible to analyze a model if i set a breakpoint with the windbg plugin and when IDA hits that breakpoint, this module is added to the IDA Modules windows.
It would be a lot easier if i could just analyze it without pre-putting a breakpoint on the specific module and waiting for it to hit.
I have an old VB6 app that uses a lot of 3rd party components, not just visual but also for audio processing, tcp/udp, VoIP, etc...
When I run the app as an EXE (e.g. not in the VB6 IDE), it will crash sometimes with a GPF. It happens after the program has been running for several days and occurs when there is no one around.
Unfortunately the user has clipped the screenshot, but it typically doesn't have any useful information anyway. The description of the crash reported that the crash occurred in ntdll.dll.
My questions:
What tools do I need in order to debug this?
How do I actually get started?
I have the PDB files from the compilation in VB6. The app is compiled to Optimize for Fast Code. What can I do with them in this situation?
I would use ntsd or windbg (link), and run the app under either of the user mode debuggers (if you're not familiar, they have the same commands - ntsd is a console debugger, while windbg is a GUI debugger). Both have a lot of command line options, but ntsd appname.exe will be enough to get started. Use the .sympath command to point the debugger toward the symbol, and you should be on your way. When the crash occurs, you can examine variables and stack in order to figure out what may be missing.
BTW - the error above is an invalid handle error, so the program probably passed a stale or NULL handle to a windows function. The debugger will tell you more.
the problem is not to debug c, php, python, etc in emacs, but debug emacs itself.
i have confronted with a segmentation fault error when i try to enter gdb mode in emacs using
Mx gdb Enter
now i have build emacs with debug info, and have load it using "gdb emacs" command.
l command shows the source code of emacs,
now my problem is how to debug emacs? where i should set that breakpoint?
howto find the origin of segmentation fault using gdb?
the following is a screenshot about what i have did now, so any suggestions how i should debug emacs? and where to set break points?
http://i1271.photobucket.com/albums/jj624/bigmeowOoO/emacs_where-i-should-set-breakpoint-when-debug-emacs.jpg
howto find the origin of segmentation fault using gdb?
Don't set any breakpoints (yet). Simply use run command. That will start emacs running (under GDB control).
In that emacs, do M-x gdb. emacs will crash (if you are lucky), and you'll get (gdb) prompt right at the crash point.
From there, use gdb to examine the state of emacs at crash point. Figure out which variables have wrong values, etc. Then figure out where these variables are set, set the breakpoints there, and repeat (just as you would if you were debugging any other program -- there is nothing special about emacs being your buggy program).
P.S. Please don't post pictures where a simple text cut/paste will convey exactly the same information.