Hi i am new to cakephp and i want to use "debug" in order to have a better view about the framework structure.
If i use var_dump($this) , inside a action, the page takes a long time to load and end up with a non structured data on screen.
I found that "debug" function shows a more elegant structure, but if i use debug($this) inside the action i end up with the well known php stack overflow :) " Allowed memory size of 268435456 bytes exhausted (tried to allocate 113621911 bytes) "
How can i work around this ?
I've made a more specific debug and it worked just fine.
Related
Im working on a data structures assignmnet and something very strange is happening ,
my structure contains of 4 avl trees , in the destructor of the structre I delete the 4 trees using delete (the trees are allocated with new in the constructor) , a method of the class is called Quit and all it does is "delete this" calling the destructor , when calling Quit and before it operates any command (before doing the "delete this" ) two of the avl trees are already null and one is with adress 0x1 and one is with legal adress but the right and left sons of the root are 0xabababababababab and 0xfeeefeeefeeefeee
so when calling the destructor and trying to delete them a SEGMENTAION FAULT or SEGTRAP accures , because 0xabababababababab is not NULL and there for the fucnction does not enter the if(!node){return;} and calls the recursively for the right son , and that where the seg fault happens , because accessing fields of 0xababababababab is like accessing fields of NULL
a pic of the structures trees before entering "Quit"
what I dont understand is when does this happen to the trees ? because when debugging , in the end of the last function before Quit the fields and trees are all 100% as expected to be so nothing of them is deleted of changed in any way in the code.
I spent days trying to find the problem , PLEASE HELP.
THANK YOU IN ADVANCE.
0xABABABAB is used by HeapAlloc() to mark "no man's land" guard bytes after allocated memory on the heap. If you access this, you probably have a buffer overflow.
0xFEEEFEEE is used by HeapFree() to mark freed heap memory. If you access this, you probably have a double free.
Note that the memory layout is different in Debug Build and Release Build. You may not get that error in debug builds.
Also note that the memory layout is different when running the app within an IDE (debugger attached from start) and when running without a debugger. You may not get that error when running from inside the IDE.
GetModuleHandle(), GetModuleInformation() return address and size information on all the loaded modules in an app. I am only interested in the first module (exe) but when using ReadProcessMemory() and calling it more than once (using the same handles and process ID) and comparing the passes I get a few differences each time.
I was expecting memory address returned to be just a code segment however this appears not to be the case. Does the module memory address and size returned by GetModuleInformatiob() include code and data?
I have tried looking around for a full description on the windows app load process but cannot find anything.
Does the module memory address and size returned by GetModuleInformation() include code and data?
Yes.
Before anyone says it, I know this isn't the way it should be done, but it's the way it was done and I'm trying to support it without rewriting it all.
I can assure you this isn't the worst bit by far.
The problem occurs when the application reads an entire file into a string variable.
Normally this work OK because the files are small, but one user created a file of 107MB and that falls over.
intFreeFile = FreeFile
Open strFilename For Binary Access Read As intFreeFile
ReadFile = String(LOF(intFreeFile), " ")
Get intFreeFile, , ReadFile
Close intFreeFile
Now, it doesn't fall over at the line
ReadFile = String(LOF(intFreeFile), " ")
but on the
Get intFreeFile, , ReadFile
So what's going on here, surely the String has done the memory allocation so why would it complain about running out of memory on the Get?
Usually reading a file involves some buffering, which takes space. I'm guessing here, but I'd look at the space needed for byte to character conversion. VB6 strings are 16 bit, but (binary) files are 8 bit. You'll need 107MB for the file content, plus 214 MB for the converted results. The string allocation only reserves the 214 MB.
You do not need that "GET" call, just remove it, you are already putting the file into a string, so there is no need to use the GET call.
ReadFile = Input(LOF(intFreeFile), intFreeFile)
I got the same error . And we just checked the taskmanager showing 100% resource usage . we found out one of the update application was taking too much ram memory and we just killed it.
this solved the issue for me. One more thing was we gone in to config settings.
START->RUN->MSCONFIG
and go to startup tab and uncheck the application that looks like a updater application or some odd application that you dont use.
I have some code (which I cannot change) that I need to get working in a native Win32 environment. This code calls mmap() and munmap(), so I have created those functions using CreateFileMapping(), MapViewOfFile(), etc., to accomplish the same thing. Initially this works fine, and the code is able to access files as expected. Unfortunately the code goes on to munmap() selected parts of the file that it no longer needs.
x = mmap(0, size, PROT_READ, MAP_SHARED, fd, 0);
...
munmap(x, hdr_size);
munmap(x + foo, bar);
...
Unfortunately, when you pass a pointer into the middle of the mapped range to UnmapViewOfFile() it destroys the entire mapping. Even worse, I can't see how I would be able to detect that this is a partial un-map request and just ignore it.
I have tried calling VirtualFree() on the range but, unsurprisingly, this produces ERROR_INVALID_PARAMETER.
I'm beginning to think that I will have to use static/global variables to track all the open memory mappings so that I can detect and ignore partial unmappings, but I hope you have a better idea...
edit:
Since I wasn't explicit enough above: the docs for UnMapViewOfFile do not accurately reflect the behavior of that function.
Un-mapping the whole view and remapping pieces is not a good solution because you can only suggest a base address for a new mapping, you can't really control it. The semantics of munmap() don't allow for a change to the base address of the still-mapped portion.
What I really need is a way to find the base address and size of a already-mapped memory area.
edit2: Now that I restate the problem that way, it looks like the VirtualQuery() function will suffice.
It is quite explicit in the MSDN Library docs for UnmapViewOfFile:
lpBaseAddress A pointer to the
base address of the mapped view of a
file that is to be unmapped. This
value must be identical to the value
returned by a previous call to the
MapViewOfFile or MapViewOfFileEx
function.
You changing the mapping by unmapping the old one and creating a new one. Unmapping bits and pieces isn't well supported, nor would it have any useful side-effects from a memory management point of view. You don't want to risk getting the address space fragmented.
You'll have to do this differently.
You could keep track each mapping and how many pages of it are still allocated by the client and only free the mapping when that counter reaches zero. The middle sections would still be mapped, but it wouldn't matter since the client wouldn't be accessing that memory anyway.
Create a global dictionary of memory mappings through this interface. When a mapping request comes through, record the address, size and number of pages that are in the range. When a unmap request is made, find out which mapping owns that address and decrease the page count by the number of pages that are being freed. When that count reaches zero, really unmap the view.
I got a ERROR_INSUFFICIENT_BUFFER error when invoking FindNextUrlCacheEntry(). Then I want to retrieve the failed entry again, using a enlarged buffer. But I found that when I invoke FindNextUrlCacheEntry(), it seems I was retrieving the one next to the failed entry. Is there any approach I can go back to retrieve the information of the just failed entry?
I also observed the same behavior on XP. I am trying to clear IE cache programmatically using WinInet APIs. The code at the following MSDN link works perfectly fine on Win7/Vista but deletes cache files in batches(multiple runs) on XP. On debugging I found that API FindNextUrlCacheEntry gives different sizes for the same entry when executed multiple times.
MSDN Link: http://support.microsoft.com/kb/815718
Here is what I am doing:
First of all I make a call to determine the size of the next URL entry
fSuccess = FindNextUrlCacheEntry(hCacheHandle, 0, &cacheEntryInfoBufferSizeInitial) // cacheEntryInfoBufferSizeInitial = 0 at this point
The above call returns false with error no as INSUFFICIENT_BUFFER and with cacheEntryInfoBufferSizeInitial parameter set equal to the size of the buffer required to retrieve the cache entry, in bytes. After allocating the required size (cacheEntryInfoBufferSizeInitial) I call the same WinInet API again expecting it to retrieve the entry successfully this time. But sometimes it fails. I see that the cases in which API fails again even though with required buffered sizes (as determined it only) because it expects morebytes then what it retrieved earlier. Most of times the difference is of few bytes but I have also seen cases where the difference is almost 4 to 5 times.
For what it's worth this seems to be solved in Vista.