I was wondering what strategies you guys are using to fix runtime errors? Really appreciate if you could share some tips!
Here is some of my thought (possibly with the help of gdb):
when runtime error happens because some memory is wrongly accessed, is the address stored in the dumped core showing where the memory is?
If I can find the address/memory whose being accessed causes the runtime error, is it possible to find out which variable is using that address (which may be at the begining or middle of the memory of the variable)? And find out the nearby variables that takes the memory down below and right above that memory block?
If all these are possible, will it help to fix the bugs?
Thanks and regards!
I use gdb's --args option to start my programs from the command-line.
Example:
gdb --args foocode --with-super-awesome-option
run
This will load the program foocode and pass the --with-super-awesome-option parameter to it. When the program fails, you'll have a ready-to-use gdb session to work within.
From there you can use the backtrace command:
bt
This will show you the chain of events (function calls) that lead to your crash.
Related
I am running plink software through a PBS batch job. This error occurs when I run the job:
*** glibc detected *** /software/plink: double free or corruption (out): 0x000000018dfafca0 ***
======= Backtrace: =========
[0x7d7691]
[0x7d8bea]
[0x45f5ed]
[0x47bb11]
[0x40669a]
[0x7bdb2c]
[0x400209]
However it only occur with one of my files (bw 30-60 gb files) and each rerun shows the exact same back trace map. I tried running it not through the batch scheduler and received the same error again, with the same backtrace map. I am just using the software (plink), and didn't write it, so most of the answers online are about writing and freeing memory in your program.
Any ideas on
what is causing this error, and
how I can fix it?
what is causing this error, and
A double-free or heap corruption in the plink
how I can fix it?
You can't. You can do one of two things, depending on how much you know and understand.
First, build the newest version of plink from source, and see if the problem persists.
If it does not, you are done (or at least you might hope that someone else found and fixed this problem).
If it does, you'll have to debug the problem sufficiently for either you, or plink developers to fix it. Some tools that should help: Valgrind and Address Sanitizer (note: in addition to Clang, Address Sanitizer is also included in GCC-4.8).
Once you have a good report (where the memory was allocated, and where it got corrupted), you should either fix it and submit your fix to plink developers, or give them a bug report with the allocation and corruption location and stack traces.
I have a very simple Delphi 2010 dll that I load from a Visiual Studio 2008 C ATL console application (MVF GUI app does not work either). When I debug the console app from the IDE directly - no break points - the output from the application is not correct but when I run the app directly or if I attach to the process with the debugger then it works 100%. Debugging the same dll from a Delphi console app (i.e. running it from the IDE) also works.
The VS debugger seems to break the app depending on how you run it. VS2010 does the same!
I have made 100% sure - several times! - that the data types and calling convention of the dll exports and those in the console app match. I can go into more detail but I don't want to confuse the matter with what may be irrelevant information. Please tell me if I have to go into the specifics of the code if what I have offered is not enough.
Has anyone experienced this sort of thing and know how to fix it?
I've got similar problem once (different behavior in IDE/debugger and in standalone application). It turned out, that I've checked the value of unset variable. Debugger allocated it (always!) in previously used block of memory, such that the value was not empty and the application worked correctly (because only the conditional block was erroneous). However, OS sometimes put the application in empty memory block (filled with 0s), the condition failed and application crashed.
Maybe this is the issue? Try using OutputDebugString()'s to track down values of variables during the library runtime. Without some source code I believe, that it's not easy to say, what might be the reason.
Best regards -- Spook.
I'm using a Java application which allows you to import custom files. On import, these files are loaded into memory.
The problem is that the files I want to import are very big, this causes an OutOfMemory exception. The crash log also informs me that the VM was started with the java parameter "-Xmx512m", I want to alter this to "-Xmx1024m" so that I got double the memory available.
The problem is that this application is using it's own JRE folder and that there's a launcher written in C which is calling the jvm.dll file. In any way, java.exe or javaw.exe are never called and thus I cannot set these parameters myself (if I delete these executables it doesn't matter, can still run the application - this is not the case with the dll).
So, my question is, can I set this VM parameter in an other way? I'm even willing to alter the JRE files if there is no other way.
Update: Found some extra info:
jvm_args: -Djava.system.class.loader=com.company.loader.NativeClassLoader -Xmx160m -Xms160m -Xincgc
java_command: unknown
Launcher Type: generic
You would probably be better off attempting to eliminate the launcher use a standard JVM. See if you can figure out what parameters Java is being launched with--it might help to dump the launcher and any associated configuration files.
Then you just call java yourself.
This may not work at all depending on what else the launcher is doing.
edit:
try:
java -Djava.system.class.loader=com.company.loader.NativeClassLoader -Xmx160m -Xms160m -Xincgc
from the command line against a real JVM. There is a good chance it will fail because of the NativeClassLoader or other stuff set up by the java loader.
Also you may be missing the actual java class it is trying to start (I don't know if that "NativeClassLoader" needs the actual main class or not).
Without knowing more about the C class loader, I don't know if anyone can help you much. Perhaps you could contact the vendor? You might dump the .exe file and see if there is any identifying text--if you could figure out where it came from, you might be able to find docs on it telling you how to forward parameters to the JVM
I'm finishing an internship at a company and have just been thrown onto this project for the last month where the program is built upon an engine that they "failed" to buy the source code for. Now I've been given the task of finding out why it is failing, on only certain conditions and customer feedback hasn't been great. The main developer for the project is also out on leave for several months.
I have the engine install and know the language it was written in (delphi6?).
note which I have never had to use
I have our products msi.
I'm expected to go through the regular app and pinpoint the problem. I suspect it is something to do with fields not being re-initialized properly.
Is there a way to attach a debugger to the exe to see callstacks and all that hotness?
Any help that would avoid countless use cases would be received gratefully.
You can attach the Delphi debugger to any running process (like all other win32 debuggers out there) but I don't think the experience will be near what you expect. Delphi produces really tight executables which means the info for building human readable callstacks or any kind of "hotness" are simply not there.
Your only chance is in that if your application is a Debug release. In that case, Delphi debugger should help more than a generic debugger.
You might also want to have a look at this thread - Is there a program to decompile Delphi?
In Delphi 2006 (not sure about 6) you can attach the debugger to a running process.
You only get assembler instructions, registers, flags, memory dump and stack (hex). Hope that is enough.
Nice, I tried to attach to the ide/debugger and they disallowed that ;-).
How to generate the Symbols file of a PowerBuilder program for dump analysis?
Are you running into a problem with a compiled PowerBuilder application?
I've never used the Microsoft debugger, however, I have used Dependency Walker and ran my app from within that environment. Usually that helps us if we have missing deployables, etc.
If you need a stack dump, have you thought about running the app from the Run window and adding the /debug option after the name of the app? That creates a call stack log that shows all your commands being called, etc. Probably would get you what you need.
Please advise.
You can install Dr. Watson (drwtsn32) to automatically create a crash dump when/if your application dies.
That said, the dump will usually only be useful if you are calling into native DLL's. Otherwise the stack will just include various PBVM calls that will be difficult to correlate back to actual source code lines.