In several of my apps, I occasionally get an exception telling “Failed to allocate a memoryblock with 8 bytes in size.” and the app shuts down. I’ve not been able to track the issue (seems like it always happens in the built app ), but just wondered whether someone else already saw this message.
Maybe your app could be suffering some memory leaks while continuously requesting 8 bytes allocations (also not releasing them as necessary or in time?).
Or you made an extremely memory hunger app tested ok in a 16Gb+ machine that blows up in 8Gb ones?
Always remove any handlers added with AddHandler when you are finished with them using RemoveHandler. Balance AddHandler with RemoveHandler in the appropriate place, e.g., if AddHandler is used when a Window opens, use RemoveHandler when the Window closes.
Thanks. I usually try to do that.
In the current project, I don’t use AddHandler, but I use AddressOf; I’m recompiling using WeakAddressOf to check if it goes better.
As it’s a random crash, I don’t know when I’ll validate whether it’s working better.
Ok, I got the issue again, and it was early (first and quick use); so I don’t think it’s about a memory full condition.
Here’s the stack log (shown in a MessageDialog from App.UnhandledException):
Unhandled exception in method CIPCS1.Error Number: 0 Message: Failed to allocate a memoryblock with 8 bytes in size. RuntimeRaiseException _Z14RaiseExceptionPKcS0_jx _Z20REALBuildMemoryblockPKvx _ZL14MyEventHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv.1008 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec SendEventToEventTargetWithOptions HIToolboxLSNotificationCallbackAllASNsFunc ___LSScheduleNotificationFunction_block_invoke_2 CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK __CFRunLoopDoBlocks __CFRunLoopRun CFRunLoopRunSpecific RunCurrentEventLoopInMode ReceiveNextEventCommon _BlockUntilNextEventMatchingListInModeWithFilter _DPSNextEvent -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] XojoFramework$5194 XojoFramework$5195 Application._CallFunctionWithExceptionHandling%%op _Z33CallFunctionWithExceptionHandlingPFvvE XojoFramework$5194 -[NSApplication run] RuntimeRun REALbasic._RuntimeRun _Main main
And, again, this happened in the built app (I can’t reproduce in the debug version).
The location of the exception is “CIPCS1.Error”, as seen in this log. CIPCS1 is an IPCSocket, and here’s the Error event code:
app.CurrentMethodDebug="CIPCS1.Error" //What's shown in the log
if PDlgReply<>nil then PDlgReply.Invoke "TERM" //A delegate
if PartialReceivedData<>"" then MessageBox "Warning: not all data was processed."+EndOfLine+PartialReceivedData //When the error occurs before the socket has handled the whole data.
app.CurrentMethodDebug=""
The delegate is assigned that way: Socket.PDlgReply=WeakAddressOf ResultReceived,Opt
And ResultReceived looks like this:
select case Data.Left(4)
case "rslt" //Got a result from the helper
Var Item As FolderItem
Var t as string=Data.Middle(4) //After “rslt”
Var SearchID as integer=t.NthField(chr(4),2).ToInteger
Var What as string=Left(t,4)
Var s as string=t.Middle(4).NthField(chr(4),1) //Path to item received
if s<>"" then Item=new FolderItem(s)
if What="ifnd" then SearchParams.Result.Add Item //Add the found item to an array
case "TERM" 'Termination (clean or not)
SearchIn SearchStep.ApplyRules
end select
Ok, I found where the problem occurred. For some reasons, under certain circumstances, the code was trying to access a timer on a window that was closed; this led to a NilObjectException. So I added a check against nil.
I have no idea why that leads to this “Failed to allocate a memoryblock with 8 bytes in size” message nor why the stack refers to REALBuildMemoryblock.
In a test project, I couldn’t reproduce the issue (I correctly get a NilObjectException). Also, with the new check against nil, the original app won’t crash anymore, so that was clearly the cause. Puzzling
If there’s anything I could try (as I don’t like to keep a mystery unsolved), feel free to ask.