When I run a code in OMNeT++ (eclipse based IDE), the simulation crashes after certain number of events. So to check for a memory leak, I used VALGRIND. When I run the code using this valgrind profiler, my simulation runs perfectly fine. I don't know the reason for this peculiar behavior. Can someone explain the reason behind this ?
Probably a 'heisenbug". I.e. an issue that changes its behavior if you try to examine it. It could be an uninitialized variable or other obscure bug that did not surface if the program starts with a different memory layout (i.e. under valgrind).
I would still look into the valgring logs, even if the crash does not occur as the logs may cotain some hints.
Related
Currently experiencing very slow debug start up times (between 25-45 seconds) with idea CE 14.1.5. To reproduce:
Make change in code that will cause javac to be invoked.
Hit debug.
Status bar shows "Make" and entire IDE hangs.
I'm using a 2015 Macbook pro and Java 1.8.0_60 64bit.
After profiling with advice from above, I tracked it down to this issue:
IntelliJ freezes for about 30 seconds before debugging
Which in turn points to an issue with InetAddress.getLocalHost() on *nix. Following the advice in this linked post certainly helped it go away:
InetAddress.getLocalHost() throws UnknownHostException
I had similar problems of starting debugging application and tried different workaround tips to figure it out, but in my case i had a lot of forgotten breakpoints marked in application and removing them all application starts and performs lightening fast.
So, my advice remove all the breakpoints from the code at least at application startup.
You should assign more memory. This almost always reduces lagging / hanging issues. You can find a guide how to change this setting in IntelliJ manual.
I have got a minigame.exe which crashes at some point inside the game. It does not show any error message and it just says Not Responding. I am using Win 7. I want to identify the crashing point and try to fix the games problem. I think the problem might be caused due to a specific DLL imported by the executable. However, I have no clue about how to find out that specific assembly line and try to patch the executable with OllyDBG.
With the information given, this answer would need a full tutorial style, which is considered as too broad for this site. But the first step, finding out what type of crash it is and where it occurs can be explained.
I'll use WinDbg as the debugger, since I'm not familiar with OllyDbg. It is is part of the Debugging Tools for Windows and it's freely available. Install the versions, x64 or x86, that matches minigame.exe.
Start WinDbg, use the correct bitness
Run minigame.exe under WinDbg (File/Open executable). It will stop at the initial breakpoint.
Set up the symbols, at least .symfix c:\debug\symbols and .reload. This will download information needed to construct the callstack.
Continue running the application with g
Reproduce the issue / wait until it crashes
When WinDbg stops,
create a crash dump with .dump /ma c:\debug\minigame.dmp so you can analyze it later, e.g. for asking questions here, so that you needn't reproduce the bug again.
get information about the exception with .exr -1
switch to the thread that caused the exception with ~#s
look at the callstack with k
Now you should have a better understanding of the crash, perhaps enough to apply a patch, maybe not. At least it's a better starting point for further exploration.
Sometimes it show up sometimes it doesn't
I wonder why.
LLDB appears to be not as good as GDB at showing the correct state of variables - e.g. sometimes, often near the start of methods, LLDB fails to figure out the type of self and you cannot see the instance variables; whereas GDB with the same code is fine.
There are sometimes other reasons; to do with accessing memory, locks, etc.; that a debugger cannot show you variables.
Whether your particular case is LLDB failing or one of those cases when GDB also would fail I cannot say, but if this is hitting you a lot in a particular project switching to GDB might be worth it for the project.
I have a program witch is a xmpp client that connect to a server.
I use gloox library to do that.
When I run the program, it runs ok and connects to the server.
But when I run it under valgrind, the program never sends
<iq id='uid:4efa1893:327b23c6' type='set' from='user#server/ressource' xmlns='jabber:client'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
to the server.
Had anybody experience such problem?
Are there any parameter I specially need to run valgrind with to make sure that it is the same environement as a normal program execution?
The very first question is: did Valgrind report any errors in the execution of your program?
If your program is well-defined, and Valgrind didn't report any errors in it, then the program is supposed to behave exactly the same way under Valgrind as without it (only slower); no special settings required.
It is somewhat more likely that Valgrind did report some errors, and if so, your program is likely not well-defined, in which case your question is mute -- your program doesn't work the same because it is not well-defined (i.e. depends on undefined behavior).
From what experience I have programming whenever a program has a problem it crashes, whether it is from an unhanded exception or a piece of code that should have been checked for errors, but was not and threw one. What would cause a program to completely freeze a system to the point of requiring a restart.
Edit: Thanks for the answers. As for the language and OS this question was inspired by me playing Fallout and the game freezing twice in an hour causing me to have to restart the xbox, so I am guessing c++.
A million different things. The most common that come to mind are:
Spawning too many threads or processes, which drowns the OS scheduler.
Gobbling too much RAM, which puts the memory manager into page-fault hell.
In a Dotnet/Java type environment its quite difficult to seize a system up, because the Runtime keeps you code at a distance from the OS.
Closer to the metal say C or C++, Assembly etc you have to play fair with the rest of the system - If you dont have it already grab a copy of Petzold and observe/experiment yourself with the amount of 'boilerplate' code to get a single Window running...
Even closer, down at the driver level all sorts of things can happen...
There are number of reasons, being internal or external that leads to deadlocked application, more general case is when something is being asked for by a program but is not given that leads to infinite waiting, the practical example to this is, a program writes some text to a file, but when it is about to open a file for writing, same file is opened by any other application, so the requesting app will wait (freeze in some cases if not coded properly) until it gets exclusive control of the file.
And a critical freeze that leads to restarting the system is when the file which is asked for is something which very important for the OS. However, you may not need to restart the system in order to get it back to normal, unless the program which was frozen is written in a language that produces native binary, i.e. C/C++ to be precise. So if application is written in a language which works with the concept of managed code, like any .NET language, it will not need a system restart to get things back to normal.
page faults, trying to access inaccessible data or memory(acces violation), incompatible data types etc.