1.36 Memory Leak...
Archives Forums/BlitzMax Bug Reports/1.36 Memory Leak...
| ||
Strict Graphics 800, 600 Local img:TImage Repeat img:TImage = CreateImage(512, 512) Cls DrawImage img, 0, 0 Flip img = Null Until KeyDown(KEY_ESCAPE) When I run this code, nothing is collected, memory usage rises at an astonishing rate, and thus, eventually, 30 or so seconds later, TaskManager is showing the app at 1.5gig memory usage (And is quite happy to keep on going), the memory counter in perfmon goes through the roof and my system eventually runs at a snail pace. I'm not 100% sure how the garbage collector works, but, after a test by Gfk, he's found the same problem, though, Cygnus has confirmed memory does Currently, Gfk has rolled back to version 1.24 and everything is okay. My specs are:- Windows XP Pro SP3 AMD Athlon(tm) 64 Processor 3500+ 2.0 GB RAM GeForce 8600 GTS 256mb Any idea's? Dabz |
| ||
| It's odd- because I have had this kind of thing happen before. I get different behaviour between 1.28, 1.32 and 1.36, with 1.36 using around 30mb more than 1.32, but for me the memory is eventually freed. [edit] I do seem to get a memory leak on my other machine. AMD64 X2 5200 (I think) 2gb Ram, Nvidia 8400, Windows 7. |
| ||
| Update: Ran the app above again, after the 1.5gig I mentioned above, around 1.6-1.7gig, the memory usage drops back down to 14 000K in TaskManager, though, the memory counter in perfmon is still sky high, and as such, my system is still crippled. Dabz |
| ||
| Granted the above code is pushing it a bit, but it serves to highlight the problem. I've been testing all previous versions from 1.18 upwards - wish I'd started at the top and gone back as it'd save some time.... The first 'broken' version I have, is 1.35rc5. Everything prior to that works perfectly: 1.18-1.34: Resource usage fluctuates between 18-60MB. This is fine. 1.35+: Resource usage goes up to over 1.5GB, at which point my system is on its knees begging for mercy. This is very, very bad. I've tested this on two systems with identical results: 1. Athlon64 X2 5000+, 2GB RAM, Nvidia 512MB 8500GT, Windows 7. 2. Intel Dualcore laptop, 2GB RAM, Intel GMA965 graphics, Windows Vista SP2. I note that the problem versions are the DX9 ones.... [edit] Just tested Blitzmax 1.35 with GLMax2dDriver - works fine. Looks like a DX9 problem. |
| ||
| [edit] Just tested Blitzmax 1.35 with GLMax2dDriver - works fine. Looks like a DX9 problem. Strict SetGraphicsDriver GLMax2DDriver() Graphics 800, 600 Local img:TImage Repeat img:TImage = CreateImage(512, 512) Cls DrawImage img, 0, 0 Flip img = Null Until KeyDown(KEY_ESCAPE) Works a treat now here too! Dabz |
| ||
| Confirmed! DX9 driver causes my laptop to kill itself too! |
| ||
| Update: Here's what happens on my 8500GT system if I leave it running for a minute or so:Ran the app above again, after the 1.5gig I mentioned above, around 1.6-1.7gig, the memory usage drops back down to 14 000K in TaskManager, though, the memory counter in perfmon is still sky high, and as such, cripples my system.  |
| ||
| Beta-testing team must of had a cracking game of Jacks and Two's for that to get through! :D <--- That was a joke BTW Dabz |
| ||
| Just a quick Q - has anybody tested this that *doesn't* get a huge memory leak? |
| ||
| Ive just tested on my rig (see sig) and with DX9 it goes up to 1.7GB and dies... |
| ||
| Problem is the local variable in the global scope. Thats a known special case when it comes to garbage collection, which is biting you here, because locals aren't touched by the GC until their scope is left which never can happen with locals on application level. use a global there or define the local variable in the loop and it should work fine. |
| ||
| On BMAX 1.28 and the unofficial DX9 module by DStastny works perfectly - it varies here from 50 to 120mb and keeps fluctuating on that. |
| ||
| Dreamora- but it works fine in gl or dx7?! only the dx9 driver does this. |
| ||
| Indeed, there's definitely an issue, but I haven't tracked it down yet. Feel free to have a look yourselves, of course... the source is provided :-p |
| ||
| Problem is the local variable in the global scope. Thats a known special case when it comes to garbage collection, which is biting you here, because locals aren't touched by the GC until their scope is left which never can happen with locals on application level. Using a Global doesn't make a jot of difference. Still a colossal memory leak.use a global there or define the local variable in the loop and it should work fine. Feel free to have a look yourselves, of course... the source is provided :-p It is, but not so many of us understand it. I prefer to keep myself as high-level as possible, and leave the low-level stuff to those who know what they're doing. :) |
| ||
| I've taken a dig into the source, but then everything turned into i dnt no wt yr tkin boot man! source cd s unrdabl. I think I tracked it down to pixmaps, but then it all went a bit over my head- I had very limited time to look at it though. |
| ||
| Debug Mode ON - Thread ON With OpenGL driver the above example starts from 9/18000 to 250.000 and then restart. In DirectX 7 loops from 18000 to 145-160000 (with CPU 98-99%) In DirectX 9 raises from 14000 to 380-42000 then get down to 14-17 and stay quite stable for minutes with a max of 38-42000. CPU changes from 3 to 96% Debug mode ON - Single Thread OpenGL - it stays in the range 17000-93000 DirectX 7 - it stays in the range 17000-86000 DirectX 9 - it raises to 230-465 with CPU 4-63% It seems that the MS garbage collector works better than the single-thread one... In any case the system becomes very slow (with DX9 driver) after closing the application (I think the OS is clearing the caching...) Tested with Bmax 1.36 on Athlon64 3500+ 1GB ram WindowsXP pro sp2 edited: the problem is not in the CreateImage commands, but in DrawImage (from my silly tests) |
| ||
| Probably not related with the bug, but there is a reason why Image/Pixmap cant' be forced to be in the 'right pixel format' as default FLAG without forcing a conversion? I mean I've tested DX9 driver and every image created MUST be converted in the 'right DX format' PF_BGRA8888 (while under OpenGL seems to be PF_RGBA8888). I think a better solutions should be: DX9 driver? CreateImage invoked? Default flags IS PF_BGRA8888, so we don't need conversion and we have a little time gain. Same for OpenGL. Just an idea... |
| ||
| this seems to fix it? d3d9max2d.bmx[60]: Type TD3D9ImageFrame Extends TImageFrame Method Delete() If Not _texture Return _texture.Release_ End Method |
| ||
| Yes, it seems to work better. I have no increments in the mem alloced (in TaskManager) (a part a 'peak' at the start to >300K then it is stable 60-173K) |
| ||
| Yep, seems to do the job here too... Cheers skid! Dabz |
| ||
| Thanks - that's it sorted for me, too. |
| ||
| Nice work all. Will this be in 1.37 or a fixed 1.36? |
| ||
| Just found out that this bug fix has introduced another major problem: http://www.blitzbasic.com/Community/posts.php?topic=88438 |
| ||
| Hi, Fix coming! |
| ||
| Hi, Fix coming! Marvellous! :D Dabz |
| ||
| Is this the same memory leak that affects code with GrabImage() http://www.blitzbasic.com/Community/posts.php?topic=88461#1004788 as the issue looks the same... DX9 gobbles up massive amounts of memory until it runs out DX7 memory usage shoots up to hundreds of Mb then drops and yoyo's between. OpenGL almost rock stead in comparison! And will the fix sort out both? |
| ||
| Just tested on BMax v1.37, looks good - using Dabz's code it goes up to 170MB then drops again. And using Arowx code it goes up to around 280MB then drops :) |
| ||
| Works fine here too :) |
   |