I’m getting an exception with one of my apps, with a frequency of less than a week between each.
The issue happens only in the built app, and the stack trace doesn’t tell me much. The app isn’t memory intensive at all (normal memory size in activity monitor, no use of AddHandler not paired with RemoveHandler, etc.).
Here’s what a message box tells me in app.UnhandledException:
OutOfMemoryException number 0: Failed to allocate a memoryblock with 8 bytes in size.
RuntimeRaiseException
_Z14RaiseExceptionPKcS0_jx
_Z20REALBuildMemoryblockPKvx
_ZL12CallEventPSNP16REALobjectStructP14OpaqueEventRefi
_ZL14MyEventHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv.657
_ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec
_ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
SendEventToEventTargetWithOptions
HIToolboxLSNotificationCallbackAllASNsFunc
I already mentioned this problem last year, but the context and knowledge has changed since then. What hasn’t changed is the lack of recognisable methods in the trace log, for someone like me, doing almost only Xojo programming.
The app uses the MBS plugin for at least monitoring processes and volumes mounting/unmounting (those are the main features that happen when idle, when the app throws these exceptions).
Could a moderator please update the title? (it doesn’t appear to be a way for me)
(e.g “Failed to allocate a memoryblock with 8 bytes in size (possibly related to MBS)”)
The message box is in my app; Xojo just raises the exception (if it’s what you meant).
Granted. I’ve installed the current one, but since this problem dates from more than one year, I don’t expect something changed (I read your release notes almost each time).
Thank you Christian, Tim and Javier, for your answers.
Edit: I can confirm the problem is still there; it just happened once more.
Tracking where the problem comes from is rather tricky. The crash log doesn’t mention a single method name from my code and so far, the “LastKnownMethodName” I’m implementing for this isn’t always the same (and, of course, CurrentMethodName isn’t helpful in UnhandledException).
Of course, I continue to search, but it’s not my priority either (it would be if it was taking less time).
Ok, I have more information.
I’ve seen two different cases for this behaviour in the last few days. One is because of a volume acting weird: if the disk is left connected overnight with the Mac sleeping, it’ll become unusable the next day, reporting “parameter error” for any action like renaming a folder and is always in use (not ejectable). I don’t expect this case is useful to you, unless there’s a unexpected connection with the other case.
The second case occurs with this code (in CarbonApplicationEventsMBS.ApplicationSwitched event):
Var p As new ProcessMBS
if IsProcessToBeHidden(LastFrontProcess) then 'The process that was front last should now be hidden
p.GetFrontProcess
if p.Name<>LastFrontProcess.Name then LastFrontProcess.Visible=False
end if
'Now, store the new front process using the passed parameter in the event.
'I don't recall why a loop is needed (instead of just calling p.GetFrontProcess), but it surely has to be a good reason I encountered initially…
p.GetFirstProcess
do
if p.MacProcessSerial=ProcessSerial then
LastFrontProcess=p
Exit
end if
if not p.GetNextProcess then
LastFrontProcess=nil
Return
end if
loop