Crash after long period of inactivity?
BlitzMax Forums/BlitzMax Programming/Crash after long period of inactivity?
| ||
| Does BlitzMax do anything that would cause a crash after a prolonged period of inactivity? My users are complaining an application crashes after being left on all night: http://www.leadwerks.com/werkspace/topic/11108-editor-crashes-after-being-left-idle-for-a-while/ Is there anything I should watch out for? Maybe a memory collection thing or something? Are there any recommendations for handling the AppSuspend / AppResume events? |
| ||
| Some times ago I discovered MaxGUI has a strange behaviour This example just opens a window and - periodically - checks the MemAlloced. I found there is an increment. I have no applications running for long time, so I can't say that this could lead to a crash. Edit: I missed to specify that the 'max' reaches a limit. It's not a constant increment. |
| ||
| I found there is an increment. Every time you create a new String, there will be an increment. This will increase until it reaches an internal maximum before the GC kicks in. That in itself is not a memory leak. Not to say there isn't one in the leadwerks app. |
| ||
| I would guess surface lost issue due to reset of graphics. Maybe test ctrl-alt-del cycling as well as changing monitor resolution while app is open to simulate power down of gpu. In a multi monitor situation you can also unplug alternating monitors to thrash the DeviceLost state. |
| ||
| maxide doesn't seem to have this kind of problem. |
| ||
| I don't know about blitz max but in android at least it is possible to setup a listener for unhandled app exceptions and then respond in whatever way you choose which could come in handy...logging/recovery etc. |
| ||
| Another thing to check is if the app loses focus due to maybe a scheduled virus check, defrag or something like that |
| ||
| I would guess surface lost issue due to reset of graphics. Maybe test ctrl-alt-del cycling as well as changing monitor resolution while app is open to simulate power down of gpu. In a multi monitor situation you can also unplug alternating monitors to thrash the DeviceLost state. That's a reasonable explanation. Is this something I can even detect? The application doesn't have any trouble with a short suspend and resume test. |
| ||
| You could try starting it and doing something else that requires the graphics system and as said changing resolution etc. |
| ||
| I think I've identified the cause of this problem: http://www.blitzmax.com/codearcs/codearcs.php?code=2815#comments |
| ||
| Hmmm, this is very concerning. I too have seen crashes that I couldn't put a finger on. Josh is completely correct about GCMemAlloced() increasing for no reason. I've come up with a dirty work around that checks how much memory is being used and forces the garbage collector to start: SuperStrict Import maxgui.drivers AppTitle="MaxGUI test" Local window:tgadget = CreateWindow(AppTitle, 100,100,400,400 ,, WINDOW_TITLEBAR | WINDOW_CENTER) Type TGarbage Field GarbageMem:Int = GCMemAlloced() Method Check() If GCMemAlloced() - GarbageMem > 65535 Then GCCollect() End If End Method Method DebugPrint() Print (GCMemAlloced() - GarbageMem) End method End Type Local tim:ttimer = CreateTimer(60) Local garbage:TGarbage = New TGarbage While True WaitEvent Select EventID() Case EVENT_TIMERTICK garbage.debugprint() garbage.check() Case EVENT_WINDOWCLOSE End End Select Wend I did a quick test on my other apps and they all suffered from exactly this error (as shown) I'll report more once I add the new collect code... |
| ||
| Hmmm, this is very concerning. There's nothing wrong with the GC. It collects as and when required. |
| ||
| The garbage collector doesn't always have 100% consistency frame to frame, but I have learned to tell the difference between normal fluctuation and a leak. If you are steadily increasing memory each frame and it doesn't stop after ten seconds, it's probably a leak. The code I linked to specifically causes a leak in the Windows API because it keeps allocating an object and never frees it. Once fixed my application's memory usage is flat and stable. |
| ||
| I too trust the GC. I've been using a program for years that I wrote in bmax that absolutely thrashes the GC by creating thousands of isolated and linked objects and destroying them a second later, forever. I'll often run 6 of these programs simultaneously ('cause multithread sux) for hours or days straight. the program doesnt eat mem, even when the occasional 'bad obj ref #' message pops up in the console. In other words, inside the bmax runtime, the GC is rock-solid. |
| ||
| That "Get Windows 'special folder' paths" code of BlitzSupport's seems like something you'd only want to call a few times when the program starts up, with the queried values cached to a variable after that. If you're calling it in your program often enough to get a memory leak then you probaly want to redo it to be more efficient. |
| ||
| seems like something you'd only want to call a few times when the program starts up That's how I thought it would be used, but Josh is right about the fact that it should release the object it allocates, so I'll update my code ASAP to avoid this happening in future! Theoretically, a path can change while a program is running, so caching the resulting path might not be ideal, but it sounds like it must have been getting called in a tight loop, which I found odd. |
| ||
| I too trust the GC. I've been using a program for years that I wrote in bmax that absolutely thrashes the GC by creating thousands of isolated and linked objects and destroying them a second later, forever. I'll often run 6 of these programs simultaneously ('cause multithread sux) for hours or days straight. the program doesnt eat mem, even when the occasional 'bad obj ref #' message pops up in the console. GW: Mind if I ask why? That sounds interesting. |
   |