Hi Aparajita, On 6/18/12 12:12 PM, "Aparajita Fishman" <[email protected]> wrote:
>> 6/18/12 7:20:10 AM [0x0-0x2ae0ade].com.4d.4d[83527] >>4D(83527,0xb6689000) malloc: *** mmap(size=16777216) failed (error >>code=12) >> 6/18/12 7:20:10 AM [0x0-0x2ae0ade].com.4d.4d[83527] *** error: can't >>allocate region >> 6/18/12 7:20:10 AM [0x0-0x2ae0ade].com.4d.4d[83527] *** set a >>breakpoint in malloc_error_break to debug >> 6/18/12 7:20:10 AM [0x0-0x2ae0ade].com.4d.4d[83527] terminate called >>after throwing an instance of 'std::bad_alloc' >> 6/18/12 7:20:10 AM [0x0-0x2ae0ade].com.4d.4d[83527] what(): >>std::bad_alloc > >That is definitely failure to allocate memory. > > >> (2) The crash occurs in my modified active4D shell when the NTK >>"TCP_Lookahead_Blob" command is called. > >You should contact Rob Lavaux then, there could be a leak in that command. I don't think this is the case, but I have already contacted him prior to this. We've been using this command for years and this problem only surfaced recently. We haven't updated that plugin. I have no doubt that this problem is self-inflicted, the trick is find out where. We've done something in A4D or via a called 4D command that is using memory that isn't being released before the request process ends. I think the problem is that we get to a point where TCP_Lookahead_Blob needs to allocate memory for a buffer and the memory isn't available. > > >> My question is what would be the best way to: >> >> (a) verify that we have a memory leak, and > >You could use in Terminal: > >top -stats command,vsize -pid <4D pid> -s 60 -l 0 | awk /^4D Server/ Thanks. I'll need to figure out how to output that to a log. These crashes are arbitrary and I have no control when the Google Box scans run. IOW, I may not be here to monitor the leak. I will see what happens if I mimic crawling with ab though. > >This would output the total memory usage including virtual memory every >minute. Change "4D Server" in /^4D Server/ to whatever the beginning of >the name of the 4D process. Assuming this will show that we are leaking memory can you or others recommend a way within a4D (or by calling 4D) to possibly capture where we're leaking memory. Are there options besides AP Available Memory? > > >> (b) isolate the cause. > >If there is any way you can not use TCP_Lookahead_Blob that would be a >start. Not until I can rewrite all of the old legacy stuff to be A4D :) Unfortunately, time and budget won't allow for that at this time. TCP_Lookahead_Blob is required to determine if the request is for an Active4D page or the legacy CGI stuff. If you recall we have a modified shell that handles both types of request. Thanks, Brad > >Regards, > > Aparajita > www.aparajitaworld.com > > "If you dare to fail, you are bound to succeed." > - Sri Chinmoy | www.srichinmoy.org > >_______________________________________________ >Active4D-dev mailing list >[email protected] >http://list.aparajitaworld.com/listinfo/active4d-dev >Archives: http://active4d-nabble.aparajitaworld.com/ _______________________________________________ Active4D-dev mailing list [email protected] http://list.aparajitaworld.com/listinfo/active4d-dev Archives: http://active4d-nabble.aparajitaworld.com/
