I used to profile a c++ app developed with eclipse CDT using valgrind (memcheck+helgrind). The application uses a static lib (libpodofo.a). After I modified and rebuild the library(podofo) the application runs fine, but valgrind says
Launching myapp(1)" has encountered a problem. Error starting process (Cannot parse PID from output file).
I have no idea where to start. Any idea?
The error apparently occurs when it tries to make calls from the library (judging by console output).
I don't know what code I could post since app runs without error.
Library is podofo.
Found the problem.
It was the code(obviously) it was a variable that hadn't been initialized, valgrind was actually killed by a null pointer.
Related
I have a program that I have written in C++ under linux (Ubuntu 10.10).
The programming and debugging worked perfectly until the moment I added the following lines to the code:
mapfile = fopen(map_filename,"wb");
fwrite(map_header,1,20,mapfile); // <-- this is the problem line
fclose(mapfile);
After I added those, the program compiles ok, but the debugger now won't start. It immediately fails with this message:
Program completed, Exit code 0x177
error while loading shared libraries: unexpected PLT reloc type 0xcc
And if I remove the line with the "fwrite", the debugger will start normally.
This problem only happends inside Netbeans.
When I debug it using the command-line "gdb" it also works ok without any problems.
Anyone have idea why its happening and how to fix it?
P.S: Those problems started recently so I assume maybe it has to do something with system updates, I'm not sure.
Found the problem:
Not long ago, I removed some old C++ projects from netbeans. It figures out that netbeans (at least v7.0) remembers all the breakpoints that I put on old projects that don't even exist in the IDE anymore.
I found this by looking at the Debugger Console (Window->Debugging->Debugging Console) and seeing that when "gdb" starts, it tries to setup all these breakpoints from other projects or from projects that do not exists (this is a bug in netbeans, btw)
The solution: I simply cleaned all the breakpoints (inside Window->Debugging->Breakpoints) and now the program can be debugged properly.
Hope this will help to anyone out there who has the similar problem.
I have been writing an application for two years in QtCreator. (My application uses some external libs).
Recently I've ported the application into Qt5.3mingw(windows7). The application built successfully but failed to start within QtCreator and gave "The program has unexpectedly finished.".
With debugging the application, it gives this error message: "During startup program exited with code 0xc0000135".
However the application starts succussfully outside of QtCreator! It seems the QtCreator has severe problem in starting the application or it's the linker problem.
I've even uninstalled all Qt and QtCreators and re-installed them, but the problem insists.
Any guide will be appreciated. Thanks.
Status code 0xC0000135 is STATUS_DLL_NOT_FOUND.
There's some DLL that your program is dependent on that is not in a directory being searched when launched from the QtCreator IDE.
You may need to make sure the PATH is set correctly for QtCreator.
Also, a tool like Dependency Walker may be able to help you figure out what DLL is the problem. I'm not sure why Windows doesn't make it easier to find out what DLL can't be found.
I developed a project on VS 2010 using c++ qt. When I run the project in debug or release mode it works great. But what I want is to run it by double clicking on the generated executable, unfortunately when I do that I get a R6010 Error .. abort has been called.
I want to solve this problem to help me creating an installer for my project.
Thank you in advance.
It happened to me exactly the same, and the problem was that the executable was reading a configuration file and some image files that were not in the same directory as the executable, and obviously nonexistent program attempted to read files so the error occurred. What I did was copy the files that are read from my program to the same directory where the executable is found and everything was arranged. Check if this is your case. Greetings!
Today I had the same error, my solution was to debug and checking if specific call of C++ function reads or writes data out of range. In my case I was trying to access to element of STL container that didn't exist.
http://www.cplusplus.com/forum/beginner/41485/
Most likely you are running out of Virtual Address space. Possibly because you are making x86 binary and that is restricting the VA space that user mode process will get. Try using x64 binary. Memory management of Win 8.1 is much better than Win 7 (Win7 becomes unresponsive when footprint reaches GBs)
I have a program written in QT that works just fine. However it has an indirect dependency on dnssd.dll since a dll loaded by the program uses bonjour. If bonjour is not installed on the machine running the program it will say
The program can't start because dnssd.dll is missing from your
computer. Try reinstalling the program to fix the problem.
I'm not loading this dll via LoadLibrary or otherwise. I linked the binary against the stub so it's loaded automatically before int main.
Obviously reinstalling the program does not fix the problem. For me it clearly says I need to install bonjour, but for most users this is extremly cryptic.
I would rather have this error message be something more informative such as "Bonjour needs to be installed for this application to work properly, go to [insert-url-here] to download it."
Is there a way to detect when a dll fails to load loke this and give a better error message?
Set it to delay load, then as early as possible (before you cause loading to happen), try to load it yourself (with LoadLibrary) and report the problem.
http://msdn.microsoft.com/en-us/library/151kt790.aspx
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