I'm debugging an executable using Application Verifier and WinDbg. I have the "Leaks" test turned on under "Basics". My problem is that when Application Verifier finds a leak, it seems to enter some kind of exception-throwing infinite loop. I get an error like this:
=======================================
VERIFIER STOP 0000000000000900: pid 0x1FE0: A heap allocation was leaked.
00000000155A6FF0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
0000000000571BE0 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
0000000012314FD8 : Address of the owner dll name. Run du <address> to read the dll name.
000007FEF8460000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
=======================================
But when I press F5to continue debugging I get the exact same message again (and again and again), just with slightly different information for the addresses.
Why is this happening? Is there a way to ignore this leak without turning off the leak checks entirely? As it stands, I can't run my program to completion to test for other issues because Application Verifier gets "hung up" on this leak.
Related
Problem :
I am executing test of my mongoose query but kernel kills my node app for OutOfMemory Reasons.
flow scenario: for a single request
/GET REQUEST -> READ document of user(eg.schema) [This schema has ref : user schema with one of its fields] -> COMPILE/REARRANGE the output of query read from mongodb [This involves filtering and looping of data] according the response format as required by the client. -> UPDATE a field of this document and SAVE it back to mongoDB again -> UPDATE REDIS -> SEND response [the above compiled response ] back to requested client
** the above fails when 100 concurrent customers do the same...
MEM - goes very low (<10MB)
CPU - MAX (>98%)
What i could figure out is the rate at which read and writes are occurring which is choking mongodb by queuing all requests and thereby delaying nodejs which causes such drastic CPU and MEM values and finally app gets killed by the kernel.
PLEASE suggest how do i proceed to achieve concurrency in such flows...
You've now met the Linux OOM Killer. Basically, all linux kernels (not just Amazon's) need to take action when they've run out of RAM, so they need to find a process to kill. Generally, this is the process that has been asking for the most memory.
Your 3 main options are:
Add swap space. You can create a swapfile on the root disk if it has enough space, or create a small EBS volume, attach it to the instance, and configure it as swap.
Move to an instance type with more RAM.
Decrease your memory usage on the instance, either by stopping/killing unused processes or reconfiguring your app.
Option 1 is probably the easiest for short-term debugging. For production performance, you'd want to look at optimizing your app's memory usage or getting an instance with more RAM.
"A Node application is an instance of a Node Process Object".link
Is there a way in which local memory on the server can be cleared every time the node application exits.
[By application exit i mean that when each individual user of the website shuts down the tab on the browser]
node.js is a single process that serves all your users. There is no specific memory associated with a given user other than any state that you yourself in your own node.js code might be storing locally in your node.js server on behalf of a given user. If you have some memory like that, then the typical ways to know when to clear out that state are as follows:
Offer a specific logout option in the web page and when the user logs out, you clear their state from memory. This doesn't catch all ways the user might disappear so this would typically be done in conjunction with other optins.
Have a recurring timer (say every 10 minutes) that automatically clears any state from an user who has not made a web request within the last hour (or however long you want the time set to). This also requires you to keep a timestamp for each user each time they access something on the site which is easy to do in a middleware function.
Have all your client pages keep a webSocket connection to the server and when that webSocket connection has been closed and not re-established for a few minutes, then you can assume that the user no longer has any page open to your site and you can clear their state from memory.
Don't store user state in memory. Instead, use a persistent database with good caching. Then, when the user is no longer using your site, their state info will just age out of the database cache gracefully.
Note: Tracking memory overall usage in node.js is not a trivial task so it's important you know exactly what you are measuring if you're tracking this. Overall process memory usage is a combination of memory that is actually being used and memory that was previously used, is currently available for reuse, but has not been given back to the OS. You obviously need to be able to track memory that is actually in use by node.js, not just memory that the process may be allocated. A heapsnapshot is one of the typical ways to track what is actually being used, not just what is allocated from the OS.
How to solve this error ultimately?
Server Error in '/****StatWCF_OData' Application.
Memory gates checking failed because the free memory (373817344 bytes) is less than 5% of total memory. As a result, the service will not be available for incoming requests. To resolve this, either reduce the load on the machine or adjust the value of minFreeMemoryPercentageToActivateService on the serviceHostingEnvironment config element.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InsufficientMemoryException: Memory gates checking failed because the free memory (373817344 bytes) is less than 5% of total memory. As a result, the service will not be available for incoming requests. To resolve this, either reduce the load on the machine or adjust the value of minFreeMemoryPercentageToActivateService on the serviceHostingEnvironment config element.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[InsufficientMemoryException: Memory gates checking failed because the free memory (373817344 bytes) is less than 5% of total memory. As a result, the service will not be available for incoming requests. To resolve this, either reduce the load on the machine or adjust the value of minFreeMemoryPercentageToActivateService on the serviceHostingEnvironment config element.]
System.ServiceModel.Activation.ServiceMemoryGates.Check(Int32 minFreeMemoryPercentage, Boolean throwOnLowMemory, UInt64& availableMemoryBytes) +121924
System.ServiceModel.HostingManager.CheckMemoryCloseIdleServices(EventTraceActivity eventTraceActivity) +86
System.ServiceModel.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity) +883
[ServiceActivationException: The service '/****StatWCF_OData/OData.svc' cannot be activated due to an exception during compilation. The exception message is: Memory gates checking failed because the free memory (373817344 bytes) is less than 5% of total memory. As a result, the service will not be available for incoming requests. To resolve this, either reduce the load on the machine or adjust the value of minFreeMemoryPercentageToActivateService on the serviceHostingEnvironment config element..]
System.Runtime.AsyncResult.End(IAsyncResult result) +650220
System.ServiceModel.Activation.HostedHttpRequestAsyncResult.End(IAsyncResult result) +210733
System.Web.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult ar) +282
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.17929
Solution is written in your post.
To resolve this, either reduce the load on the machine or adjust the
value of minFreeMemoryPercentageToActivateService on the
serviceHostingEnvironment config element.
The easiest way just add this into your web.config
<system.serviceModel>
<serviceHostingEnvironment minFreeMemoryPercentageToActivateService="0" />
</system.serviceModel>
Read more about serviceHostingEnvironment here.
Anyway how #Mr Grok correctly pointed it is an indication that your machine doesn't have enough physical memory and you should figure out why is this happening. It can be a serious problem.
I had this problem. Turns out SQL server was using over 29 gb of my available 32 gb.
Check your SQL Server if you have one. MS SQL Sever is designed to take up as much free space as you allow it. You can limit this in the maximum server memory box in the property tabs of the SQL Server.
I added serviceHostingEnvironment attribute to 0 in web.config.
<system.serviceModel>
<serviceHostingEnvironment minFreeMemoryPercentageToActivateService="0" />
</system.serviceModel>
This is the sipmplest way i found of doing this.
Well I had the same issue and I was looking for the solution. Most of the blogs were suggesting the same solution to add 'serviceHostingEnvironment' attribute in the web.config which is risky job as adding an attribute will effect entire IIS and it's hosted solutions and will restart IIS ultimately.
As error message was related to 'Memory storage issue' and we were asked to reduce the load on the server so what I did is just restarted SQL Server (MSSQLSERVER) service through service manager and everything gets back to normal and I got rid of the memory issue.
Window + R > services.msc > Restart Below Highlighted Service
The web.config worked for me, but also the SQL Server memory was an issue that needed addressed.
I was able to resolve the sql server memory issue without restarting the MSSQL server processes simply by reducing the server properties memory Maximum server memory to a lower value. The default was the effectively unlimited.
Without a MS SQL Service restart, the process automatically started reducing the memory footprint to the configured value.
I tried setting minFreeMemoryPercentageToActivateService="0" in the web.config files, but this still didn't fix in my case.
I'm using VMWare and it's performing super slow because I have too many snapshots!! I deleted the old ones, cleaned up some disk space and restarted the server and doing so resolved all the errors.
I'm new to VMWare and SharePoint, thought I could share my experience here!
Add this to your machine.config under the system.serviceModel section, which will set it for all sites:
<serviceHostingEnvironment minFreeMemoryPercentageToActivateService="0" />
You need Administrator privileges to edit this file.
See this answer on how to find machine.config.
You can check if there are any processes using excess memory before adding this setting. However for me, the default setting did more harm than good because there was a lot of "Standby" memory that was being used that can be ejected by the system when it is needed, so the system was not really out of memory.
You need to restart IIS using the IISReset command-line utility
From the Start menu, click Run.
In the Open box, type cmd, and click OK.
At the command prompt, type: iisreset /noforce
IIS attempts to stop all services before restarting. The IISReset command-line utility waits up to one minute for all services to stop.
I am facing these exceptions regularly, everytime I have to restart the server. The Exceptions are:
exception:1-> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet success
fully received from the server was 61,316,033 milliseconds ago. The last packet
sent successfully to the server was 61,316,034 milliseconds ago. is longer than
the server configured value of 'wait_timeout'. You should consider either expir
ing and/or testing connection validity before use in your application, increasin
g the server configured values for client timeouts, or using the Connector/J con
nection property 'autoReconnect=true' to avoid this problem.
exception:2->Exception in thread "ajp-bio-8009-exec-106" java.lang.OutOfMemoryError: PermGen
space
exception:3->Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
The server specifications are: 1 GB RAM| 1000 GB Bandwidth
Please also give me tips on how to manage the RAM amongst the various applications on the server and how to self kill the process which are not in working now. According to my research what I believe is processes are not getting killed and the memory once allocated to them is not refreshed back and get aligned for that process till the server reboots. So please help me with this.
I will be really grateful!
Thanks & Regards
Romel Jain
for the permgen space error, maybe cloud you add some jvm options (or CATALINA_OPTS) like this :
-XX:MaxPermSize=256m -XX:+CMSClassUnloadingEnabled
XX:MaxPermSize : permanent space size
XX:+CMSClassUnloadingEnabled: allow the jvm to unload unused class definitions
i was talking about this error in an old french post here
When I run my Windows Application(MFC) I get two Warnings.
First-chance exception at 0x01046a44 in XXX.exe: 0xC0000005: Access violation reading location 0x00000048.
First-chance exception at 0x75fdb9bc (KernelBase.dll) in XXX.exe: 0x000006BA: The RPC server is unavailable.
May I know what they mean?
What is a first chance exception?
When an application is being debugged, the debugger gets notified whenever an exception is encountered. At this point, the application is suspended and the debugger decides how to handle the exception. The first pass through this mechanism is called a "first chance" exception. Depending on the debugger's configuration, it will either resume the application and pass the exception on or it will leave the application suspended and enter debug mode. If the application handles the exception, it continues to run normally.
See this Article for more details.
This error means, that code from ntdll tries to access virtual address 0x00000048, that is not accessible. Maybe you call some function from ntdll and pass invalid pointer as a parameter.
An access violation is where you're trying to read a memory address that isn't yours; given the read address is very low in memory, I would guess that you've got a pointer to a class or struct that is actually null, and your code is attempting to access one of its members.