I'm debugging a shared library. I found that the bug can be trigger when I enable ASLR in Linux host, while the bug disappears when ASLR is disabled.
I want to further debug the shared library with gdb. But I found it always loaded the shared library at a fixed address, which made the bug disappear.
Is there any way to disable this gdb's feature?
Is there any way to disable this gdb's feature?
Yes, you can set disable-randomization off before running the program.
See this part of gdb documentation:
set disable-randomization off
Leave the behavior of the started executable unchanged. Some bugs rear their ugly heads only when the program is loaded at certain
addresses. If your bug disappears when you run the program under GDB,
that might be because GDB by default disables the address
randomization on platforms, such as GNU/Linux, which do that for
stand-alone programs. Use set disable-randomization off to try to
reproduce such elusive bugs.
Related
c++ program terminated with no exceptions or stacktrace
I have a multi threaded application
If one of my threads has an access violation with reading out of bounds on an array (or any seg fault condition) my entire application immediately terminates.
If this happens on my windows counter part using visual studio I get a nice stacktrace of where the error was, and what the issue was.
I desperately need this type of debugging environment to be able to succeed at my project. I have too many threads and too many developers running different parts of the project to have one person not handle an exception properly and it destroys the entire project.
I am running Fedora Core 14
I am compiling with gcc 4.5.1
gdb is fedora 7.2-16.fc14
My IDE is eclipse Juno I am using the CDT builder
my toolchain is the cross GCC and my builder is the CDT Internal Builder
Is there ANY setting for the gdb or gcc or eclipse that will help me detect these type of situations?
That's what's supposed to happen. Under Unix, you get a full
core dump (which you can examine in the debugger), provided
you've authorized them. (ulimits -c—traditionally, they
were authorized by default, but Linux seems to have changed
this.)
Of course, to get any useful information from the core dump,
you'll need to have compiled the code with symbol information,
and not stripped it later. (On the other hand, you can copy the
core dump from your users machine onto your development machine,
and see what happened there.)
You're definitely looking for core dumps, as James Kanze wrote.
I would just add that core dumps will show you where the program crashed, which is not necessarily the same place as where the problem (memory corruption etc.) occurred. And of course some out-of-bounds reads/writes may not exhibit themselves by crashing immediately.
You can narrow the search by enabling check for incorrect memory allocations/deallocations in glibc. The simplest way is to set environmental variable MALLOC_CHECK_. Set it to 2 and glibc will check for heap corruption with every memory allocation/deallocation and abort the program when it founds any problem (producing a core dump, if enabled). This often helps to get closer to the real problem.
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html
Very basic question.
I want to debug release version of my exe. My debug version is working fine. But release version crashing as usual.
Any tool or debugger available for this would be a great help.
You can still enable debug information in release mode, and use a debugger as usual. Nothing particular here, except that the order of instructions will sometimes look weird when debugging due to optimizations.
Good luck, debugging release-mode-only bugs is tedious.
I'd recommend you adding some kind of logging system or trace points to locate the source of crash. The debugger can trick you when debugging release. You can also elevate the warning level of your compiler to see some usual suspects such as use of unitialized variables.
I recommend you to run exe under some memory debugger, such as Rational Purify or BoundsChecker. It will spot memory related bugs in your code, if any.
I am starting to ship Qt applications built using MinGW and have a question about debug logs. When using code compiled with MSVC, if my app were to crash a log file or mini-dump could be created that was invaluable when diagnosing the problem. There is even a very cool library called crashrpt that can generate and then email this log file back home automatically.
Will I be blessed with the same debugging logs when an application built using gcc crashes? If not, are there any tools out there that can produce useful logs that I can use to diagnose problems?
By default applications compiled with GCC do not produce a log when they crash - you will have to do that yourself somehow. On some platforms (not Windows), they may produce a core dump, which can be used for debugging, but this is nothing to do with GCC specifically.
(old question, answer for fellow googlers)
Gcc has a verbose termination handler which is more limited but could still be useful.
It attempts to display the cause of unwanted termination, most likely uncaught exceptions.
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx
I want to debug an application in Linux.
The application is created in C++. The GUI is created using QT.
The GUI is linked with a static library that can be treated as the back end of the application.
I want to debug the static library but am not sure how to do that.
I tried using gdb
gdb GUI
But how can I attach the library?
Has anyone had experience in debugging libraries in linux?
gdb will automatically debug functions in the library when they are called. just call it like
gdb ./foo
run
:) . Be sure you build foo with debugging flags (-g3 will enable all debugging stuffs for gcc :). You should not optimize when debugging (pass at most -O1 to gcc, do not optimize further). It can confuse the debugger.
If you want to debug the library code itself, you'll need to build the library with the -g compiler flag (as well as building the executable with -g as litb pointed out). Otherwise gdb will step through your code fine but will throw up its hands each time you make a library call.
You can Try KDbg, DDD - Data Display Debugger, Code::Blocks
Ulike DDD, others are IDE with debugger integrated but core debugger [gdb] remains same in those IDE. only thing is that you will get oragnized view of debugger view in GUI.
Also try Eclipse+CDT pluggin. it's also good.
A little-known alternative is gdbtui which uses a curses based interface.
You can also use Kdbg or ddd