I don't suppose there is a way to programmatically enable/disable Valgrind memcheck the way you can with callgrind? (Start/stop instrumentation).
It's painfully, unusably slow (which is okay if the code you want to test starts automatically and you just leave it running), but I can't actually get into the code that's important without clicking a few buttons in the app, which is rendered completely unresponsive. (My code is a plug-in to another app)
Thanks
It's pretty nearly impossible in principle. If valgrind doesn't know the complete history of all your memory, how can it know for sure that something is a leak, or even a reference to invalid memory?
You can't stop/start instrumentation but you can programmatically do incremental leak checks. See http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs and specifically VALGRIND_DO_LEAK_CHECK, VALGRIND_DO_ADDED_LEAK_CHECK and VALGRIND_DO_CHANGED_LEAK_CHECK.
Related
When running my asmjs\emscripten application, compiled from C++, it has suddenly started to log: "run() called, but dependencies remain, so not running" to the web console, and nothing more happens.
I've added some cout's at the absolute start of my main, but even they aren't reached.
The application executed successfully before, but suddenly this started to happen and I don't know what change triggered this.
Does anyone know how to debug this?
Update
After removing as much source code as I could, this happens as soon as I #include , even due my main simply consists of a single cout.
Ideally you would have the entire environment when it was running in version control, and build every version since to see where it broke.
You might have your code in version control, but perhaps not Emscripten itself. If you've updated Emscripten, this could lead to differences in behaviour. I would try going back to whatever version you used when it was running. Note that sometimes various cache directories survive an Emscripten version change, and might need to be cleared manually (I forgot which exactly).
The dependencies remaining could mean that you are trying to do something before Emscripten has loaded any other files it needs to, say files requested by --preload-file or --memory-init-file. Note that according to https://kripken.github.io/emscripten-site/docs/getting_started/FAQ.html#faq-when-safe-to-call-compiled-functions you should not try to run any Emscripten functions, until the C++ main function has run. To detect this, you can, for example, call your own Javascript function from main (there are other ways).
The fact this wasn't causing a problem before could have been something that seems quite unrelated: a change or update in the web browser, changing limits of concurrent downloads, or a change in the web server this is running from. You could look in the Network tab in the browser to see if anything leaps out at you as being different or suspicious.
However, as main isn't even reached, then it might not be that. I would try commenting out virtually all of your code, and make it so you have practically nothing but a hello-world program. Perhaps you don't have a correct setting in the Module object, or maybe the request for the memory initialization file is failing (you can check in the Network tab in the browser for that one). If your basic hello world program still isn't working, then you could post again, with its code, in a separate question.
This can also happens when the browser runs out of memory. Unfortunately, the browser's memory handling is not in our control so there isn't much you can do beside reducing your payload. This includes code size, preload content size, etc. Basically anything that can reduce the total memory consumption of your program will help fixing this. Browser vendors are constantly working to improve this, but it's going to take a while still.
I think you haven't given enough information to really know for sure. But it might be for instance that your js suddenly crossed some memory threshold which exceeds what the browser wants to allocate to it. You could try reducing the amount of memory used / streaming some assets instead of preloading them / ship less code / use -Os optimization level?
We have a problem for which I am looking for a direction. We have an old MFC based application, and due to various reasons, the application is crashing sometimes intermittently in some weird scenarios. And even the customers who are using our application and getting these crashes are finding difficulty in identifying the pattern of crash. So, I had a thought that, if we can have a mechanism by which we can generate a log whenever the application crashes. Like for example, the call stack or any other information in that log. I know,, we can use the crash dump in this case, but then I feel like having a log is a better option. So any help or information in this regard would be really helpful.
Thank you.
You can find a good implementation of crash reporter in the link here.
When you compile your release build, make sure that both DEBUG and /MAP are enabled. Store your binaries together with your .map files and let your customer run this version until a crash is produced. In the Event Viewer you will then find a crash log with a crash offset. Then debug step into your code (F10) and use the crash offset together with some nifty tricks and tricks to jump (set the EIP register to... well, you have to google this a bit) to the location where the crash occurred. You should now be able to find the error!
I have an MFC application which needs to display a webpage. I've added a CHtmlView through CSingleDocTemplate which spawns a window and displays the page fine but it leaks memory when running javascript.
The page I'm looking at is genereated by Madcap flare and so it very heavy with javascript. I'm losing about 4K a second just sitting watching the page.
I've tried to reduce the problem by letting the user close the document but then I run into a problem with not knowing if the CFrameWnd was closed or not in the main application so not knowing if I need to create a new one or just reuse it.
I'm running this on windows 7 with IE9 installed so if I'm right I should be well clear of the old IE javascript circular references bug.
Does it happen in both Release and Debug build? I've seen similar (somewhat deterministic) errors when freeing dangling pointers or blowing the stack. With a bit of bad luck, the undefined behavior from faulty code could produce memory leaks.
Try enabling all possible runtime checks in your build and see if the error goes away (or is somehow detected).
Try commenting out large code blocks and see if the error goes away.
I'm just guessing here :)
Looking at Coldfusion's Server Monitor, I see many requests with averages from 100KB to 700KB average memory usage. This seems high to me, is it?
If it is high, it would explain why the server seems to love to eat up RAM and never let it go. What would be a good way of finding out why the memory usage is so high. There is nothing that I can think of that would be using this much memory. Are there any good ways of debugging Coldfusion requests?
We've had good luck with SeeFusion and simply using Jconsole on the servers to monitor memory and threads.
One thing we did find is that during the time in which the data is being rendered to be returned to the user the memory usage was highest. Once the form was displayed memory dropped off significantly. Make sure garbage collection is set properly, as well.
Are you actually getting 'out of memory' exceptions? Or 'out of stack space' errors? Check the logs carefully as I had experience with CF restarted spontaneaouly before - check the server.log files.
If the answer is yes, then - as mentioned - you can use a tool like JConsole to monitor memory usage. If you see that memory goes up and up prior to these exceptions then you need to find out where your memory leak is. The best way to do this is to get a dump of the JVM at that time and use a meomry analysis tool. I documented our experience with this.
If there are no exceptions etc. then be aware than JRun does use a lot of memory. Typically between 500MB and 1.5GB on our Win32 servers even if the CF Admin setting for the JVM heap size is 1024MB. JRun and is running on top of Java, running an application server so this will be high enough. What you need to watch out for is an ever-increasing use of memory using JConsole.
As for GC tuning - only mess with these settings if you really have a problem. It's complicated and will result in server instability if done incorrectly or without understanding of how Java GC works. You can get the basics here, and then you can pass the settings (e.g. -XX:MaxPermSize=192m) as JVM argument in CF admin.
Getting to the bottom of memory issues can be challenging and time consuming so best of luck!
Sounds like a memory leak. You want to generate a JVM heap dump - a snapshot of JVM memory. Easiest way to do so is with jvisualvm. Then analyze that snapshot using the Leaks Report in Eclipse Memory Analyzer. Marc Escher has a blog entry on this topic.
Steps to Setup a JVM JMX Port for getting a ColdFusion Heap Dump
Edit jvm.config and add to java.args: -Dcom.sun.management.jmxremote.port=3333 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true
Copy \ColdFusion9\runtime\jre\lib\management\jmxremote.access.template -> jxmremote.access
Edit jxmremote.access add "controlRole changeIt" to the end of the file replacing "changeIt" with password of your choice
In Windows Explorer > jxmremote.access > Right Click > Properties > Security > Advanced
Owner > Administrators
Permissions > Uncheck "Allow inheritable...." > Dialog Click "Copy"
Add "Administrators" with Full Control
Remove all other Permission entries
Click "OK"
Restart ColdFusion
Generating a Heap Dump
on ColdFusion box install the JDK
run jvisualvm from jdk-install-dir/bin/jvisualvm
open a JMX connection (e.g. localhost:3333)
on the "monitor" tab click the Heap Dump button and save the result by right clicking its node
take this file and open in Eclipse Memory Analyzer and run the Leaks Report
dig through it, use the Eclipse help to understand how to evaluate
I've used this approach to find a number of memory leaks in ColdFusion code.
I am trying to make a program that records a whole bunch of things periodically.
The specific reason is that if it bluescreens, a developer can go back and check a lot of the environment and see what was going on around that time.
My problem, is their a way to cause a bluescreen?
Maybe with a windowsAPI call (ZeroMemory maybe?).
Anywhoo, if you can think of a way to cause a bluescreen on call I would be thankful.
The computer I am testing this on is designed to take stuff like this haha.
by the way the language I am using is C\C++.
Thank you
You can configure a machine to crash on a keystroke (Ctrl-ScrollLock)
http://support.microsoft.com/kb/244139
Since it appears that there are times when that won't work on some systems with USB keyboards, you can also get the Debugging Tools for Windows, install the kernel debugger, and use the ".crash" command to force a bugcheck.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
In order to cause a BSOD, a driver running in kernel mode needs to cause it. If you really want to do this, you can write a driver which exposes KeBugCheck to usermode.
http://msdn.microsoft.com/en-us/library/ms801640.aspx
Thanks to Andrew below for pointing this utility out:
http://download.sysinternals.com/files/NotMyFault.zip
If you kill the csrss process you'll get a blue-screen rather quickly.
If you want to simulate a hard crash such as a bluescreen, you'd pretty much have to yank the power cord. NOT recommended.
In case of a crash, anything not saved to persistent storage will be lost. If you want to simulate a crash for purposes of logging, write a "kill switch" into your logger, which stops the logging. Now you can simulate a crash by killing the logging and making sure you have the data you would have wanted in case of an actual crash.
First of all, I would advise you to use a Virtual Machine to test this BSOD on. This will allow you to keep a backup just in case the BSOD does some damage to the system. Here's a tip on how to generate a BSOD simply by pressing CTRL+SCROLLLOCK+SCROLLLOCK.
Is there a Windows API to generate one? No, according to this article. Still, if you would call certain API's with invalid data, they could still cause a crash inside the kernel, which would result in your BSOD.
I'm not sure exactly what you'd be testing. Since your program runs periodically, surely it's enough to check that the information is being dumped at the frequency that you specify while the system is running? Are you checking that the information stays around after the blue screen? Depending on how you are dumping it (and whether you are flushing buffers), this may not be necessary.
If you dont want to write code (driver, IOCTL...) you can use DiskCryptor. Note that no disk encrypting is need.
Just need to install the driver:
dcinst.exe -setup
And then generate a bsod using the DC console:
dccon.exe -bsod
Run process as critic and exit http://waleedassar.blogspot.co.uk/2012/03/rtlsetprocessiscritical.html