I know what this error means, the unusual thing it whats throwing it.
EntitySave(arguments.entity);
gives me a
java.lang.OutOfMemoryError: Java heap space
why?
note: there are no dumps nor anything else throwing this error.
Right, found the answer. Sorry I did not give a lot of information still new to ORM and did not know how to view logs.
Anyhow what I found is that 'out of memory' only happened on 'insert'. looking at my entity I included a preInsert() function, in this function I had...
if(structKeyExists(this,"SETCREATEDBY")){
local.accountuser = getService("accountService").getAccountLoggedIn();
writeDump(this);
this.setcreatedBy(local.accountuser);
}
So yes my bad I did have a dump!!!! So sorry for wasting your time a lesson learned I promise! :)
Related
Using the following code on VS 2012, native C++ development:
SIZE_T CppUnitTests_MemoryValidation::TakeMemoryUsageSnapshot() {
PROCESS_MEMORY_COUNTERS_EX processMemoryCounter;
GetProcessMemoryInfo(GetCurrentProcess(), (PROCESS_MEMORY_COUNTERS*)
&processMemoryCounter, sizeof(processMemoryCounter));
return processMemoryCounter.PrivateUsage;
}
I call this method before and after each CPPUnitTest and calculate the difference of the PrivateUsage field. Normally this difference should be zero, assuming my memory allocation doesn't leak.
Only simple things happen inside my test class. Even without any memory allocation, just creating an instance of my test class and releasing it again, sometimes (not in every test iteration) the difference gets above zero, so this scheme seems to be non-deterministic.
Is there somebody with more insight than me who could either explain how to tackle this or tell me what is wrong with my assumptions?
In short, your assumptions are not correct. There can be a lot of other things going on in your process that perform memory allocation (the Event Tracing thread, and any others created by third-party add-ons on your system) so it is not surprising to see memory use go up occasionally.
Following Hans Passants debug allocator link, I noticed some more information about memory leak detection instrumentation by Microsoft, in special the _CrtMemCheckpoint function(s).
The link i followed was "http://msdn.microsoft.com/en-us/library/5tz9b54s(v=vs.90).aspx"
Now when taking my memory snapshots with this function and checking for a difference using the _CrtMemDifference function, this seems to work reliable and deterministic.
When I throw in a method A, it causes buffer overrun but when I return, it runs fine.
I thought throw moves execution to the caller method so the address it goes to should be the same as return address, but i am obviuosly wrong.
Is there a way to see what address throw goes to in Visual Studio debugger?
Thank you
Berkus:
does this mean that stack of upper caller method is corrupted? So for example,
Method A calls
Method B calls
Method C. Method C throws an exception
Then, it is possible that Method C's return address is ok but Method B's return address is corrupted, causing buffer overrun? What I am seeing is that if there is no throw, my application runs fine, so I think Method A,B and C all have valid return addresses.
Throw will unwind the stack, until it reaches the function with catch in it. The return address does not matter, as throw can go up several levels of stack frames if necessary.
In C++, if you have no try/catch block then this:
Method A calls
Method B calls
Method C. Method C throws an exception
will terminate the application. You must have a try/catch block in your code if want to avoid termination.
Exactly how return addresses and thrown exceptions interact is left to the details of how your particular compiler implements exception handling. To say anything about it with much certainty, someone here would have to be familiar with those internal details.
It's certainly conceivable that a buffer overrun could corrupt data that is only used by the exception handling (thus causing a throw to fail) while leaving the return address intact (thus allowing a normal return to succeed). But again, that depends on how your compiler is making use of the stack. (On a different compiler you might get totally different symptoms). It's also possible that the corruption has caused other problems that you simply haven't noticed yet. Or that such corruption will cause problems in the future after the next time you change your code. If the stack (or other memory that C++ depends on) becomes corrupted, then just about anything could happen.
Wither some educated guess-work or knowledge of the compiler details, I'm sure someone could eventually answer the specific questions about return addresses and how throwing works. However, I really think these are the wrong questions to be asking.
If you actually know you have a buffer overrun, then there's no point in trying to answer these questions. Just fix the overrun.
If you only suspect you have an overrun or are trying to track down how it's happening, then try stepping through your code in the debugger and watch for changes to memory outside the bounds of your variables. Or perhaps, alter your function to always throw and then start commenting out suspicious parts of your process one by one. Once the throw starts working again, you can then take a closer look at the code you last commented since the problem is most likely there. If these suggestions don't help, then I think the real question to ask here is "How do I track down memory corruption that only affects throwing an exception?".
In a C++ project, I use the JNI invocation API to launch a JVM. I've done a little wrapper arount the JVM so I can use all the needed parts in a OO fashion. So far that works great.
Now, if the JVM does not start (JNI_CreateJavaVM returns a value < 0) I'd like to raise an exception within my C++ code.But if I throw an exception after JNI_CreateJavaVM, I get a buffer overrun. If I raise the exception without the JNI_CreateJavaVM call, it works as expected.
Does anyone have a clue on what the issue could be here? Or how to debug this?
Environment: Windows, Visual Studio 2008
JDK: jrockit27.6jdk16005, but happens with SUN stock one as well
Cheers
Dominik
Looks to me like you are throwing a pointer or reference to an invalid memory. It's a good idea to throw an exception by reference, but make sure that the object is not on the stack. If the object was allocated using 'new', you'll need to manage this properly (otherwise you'll have leaks). My approach is to try and throw const objects as much as possible.
Does this help?
While running my program I get this error:
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_S_create
Abort trap
I know that you can't do much without the code but I think that this error is too deep in the code to copy all of it. Maybe I can figure it out if I understand what this error means.
Is this a sign for an issue with reading or writing at the wrong memory address?
Is there something I can do to get more information about the problem from my program?
It means you tried to create a string bigger than std::string::max_size().
http://msdn.microsoft.com/en-us/library/as4axahk(VS.80).aspx
An exception of type length_error Class
is thrown when an operation produces a
string with a length greater than the
maximum size.
I know this is a old question but I just ran into the same issue.
Using Linux with gcc.
Disassembling the function showed a lot of jumps in the code, where the exception was thrown, which shouldn't be there.
In the end, a Clean Build resolved the issue for me.
This is an error in debug mode with VS2005. When I change it to release mode, everything works.
Well, the vc debug runtime causes this, that's all.
I'm running my C++ program in gdb. I'm not real experienced with gdb, but I'm getting messages like:
warning: HEAP[test.exe]:
warning: Heap block at 064EA560 modified at 064EA569 past requested size of 1
How can I track down where this is happening at? Viewing the memory doesn't give me any clues.
Thanks!
So you're busting your heap. Here's a nice GDB tutorial to keep in mind.
My normal practice is to set a break in known good part of the code. Once it gets there step through until you error out. Normally you can determine the problem that way.
Because you're getting a heap error I'd assume it has to do with something you're putting on the heap so pay special attention to variables (I think you can use print in GDB to determine it's memory address and that may be able to sync you with where your erroring out). You should also remember that entering functions and returning from functions play with the heap so they may be where your problem lies (especially if you messed your heap before returning from a function).
You can probably use a feature called a "watch point". This is like a break point but the debugger stops when the memory is modified.
I gave a rough idea on how to use this in an answer to a different question.
If you can use other tools, I highly recommend trying out Valgrind. It is an instrumentation framework, that can run your code in a manner that allows it to, typically, stop at the exact instruction that causes the error. Heap errors are usually easy to find, this way.
One thing you can try, as this is the same sort of thing as the standard libc, with the MALLOC_CHECK_ envronment variable configured (man libc).
If you keep from exiting gdb (if your application quit's, just use "r" to re-run it), you can setup a memory breakpoint at that address, "hbreak 0x64EA569", also use "help hbreak" to configure condition's or other breakpoitn enable/disable options to prevent excessively entering that breakpoint....
You can just configure a log file, set log ... setup a stack trace on every break, "display/bt -4", then hit r, and just hold down the enter key and let it scroll by
"or use c ## to continue x times... etc..", eventually you will see that same assertion, then you will now have (due to the display/bt) a stacktrace which you can corolate to what code was modifying on that address...
I had similar problem when I was trying to realloc array of pointers to my structures, but instead I was reallocating as array of ints (because I got the code from tutorial and forgot to change it). The compiler wasnt correcting me because it cannot be checked whats in size argument.
My variable was:
itemsetList_t ** iteration_isets;
So in realloc instead of having:
iteration_isets = realloc(iteration_isets, sizeof(itemsetList_t *) * max_elem);
I had:
iteration_isets = realloc(iteration_isets, sizeof(int) * max_elem);
And this caused my heap problem.