Yep,On a unit that experiences the issue the GC is kicking in and freeing Globals. DX9 uses a little 'texture store' to hold onto its textures, as to the history of how that came into being I don't know, but the GC frees the contents of the store and frees the store itself. When a new TImage wants to add a new texture to the store you get an EAV. This happens only when Incbin'ning the large 9MB file, and the code then loads in a 'biggish' texture - all are Incbin'ned. The store is a Global TList of TAutoRelease instances which are home to the textures ( as well as the texture instance in the TImage ) - as to why this store exists I'm not actually sure as it seems a bit pointless to me.The most annoying part is that the exact same exe will work on one unit but fail on another. They all have 8GB of RAM.I'm very suspicious that the GC error is actually a side effect of something else.Also when the EAV occurs the GC carries on allocating memory - so it also looks like allocation within the GC itself is happening in a separate thread.The problem seems related to having a Global within a Type and creating an instance of that Global variable without creating an instance of the Type. When the Global is outside of the Type the issue doesn't seem to occur, not yet anyway ( remember that this could be a red-herring as to the real fault as that sort of code should be valid ).
As asked right before: is it happening in NG _and_ vanilla or just one of them?NG uses a different GC than vanilla.So if it was a GC bug it should only happen in either NG _or_ vanilla.If it was a bug in Blitzmax ("ref counting") then it should fail in both.If it only fails in NG _or_ vanilla it might also be an issue with the used modules (vanilla vs maxmods/brl.mod|pub.mod vs bmx-ng/brl.mod|pub.mod).@ red herringIf the issue with "globals" exists, then you should be able to recreate the bug without the fontmachine-code (just incbin a 9mb "random data"-block - or even better some "validateable/predictable" data block - like a 1.000.000 times repeated pattern like 012345789).Also: if the global contains a custom type you could use its "Delete()"-method to print out when it gets GC'd. Similar to what we've done in the linked issue above.byeRon
Quote from: Derron on July 02, 2018, 05:24:05 PMAs asked right before: is it happening in NG _and_ vanilla or just one of them?NG uses a different GC than vanilla.So if it was a GC bug it should only happen in either NG _or_ vanilla.If it was a bug in Blitzmax ("ref counting") then it should fail in both.If it only fails in NG _or_ vanilla it might also be an issue with the used modules (vanilla vs maxmods/brl.mod|pub.mod vs bmx-ng/brl.mod|pub.mod).@ red herringIf the issue with "globals" exists, then you should be able to recreate the bug without the fontmachine-code (just incbin a 9mb "random data"-block - or even better some "validateable/predictable" data block - like a 1.000.000 times repeated pattern like 012345789).Also: if the global contains a custom type you could use its "Delete()"-method to print out when it gets GC'd. Similar to what we've done in the linked issue above.byeRonYou asked if it's in NG too, which as Col said, 'yup'. In terms of this bug, we're only testing with NG, at least i am. I'm not using vanilla blitzmax at all.--Yes... The bug occurs with and without fontmachine. It has nothing to do with my font or the fontmachine at this point as it immediately trashes Sounds and Image too.All i can say for certain as this is a GC issue for DX9. This problem does not exist in GL, to my knowledge, as 'crashing' code works flawlessly when switching the render mode to GL in my configuration file.However, Col may very well be right in terms of that something could just be affecting GC in DX9 mode. There's a few possibilities.--This is my framework:Framework brl.D3D9Max2DImport brl.glmax2dImport brl.RandomImport brl.TimerdefaultImport BRL.RamStreamImport BRL.PolledInputImport BRL.StreamImport BRL.RetroImport brl.PNGLoaderImport brl.jpgloaderImport brl.bmploaderImport brl.mathImport brl.oggloaderImport pub.Win32 Import pub.freejoyImport blide.fontmachine
If the issue with "globals" exists, then you should be able to recreate the bug without the fontmachine-code (just incbin a 9mb "random data"-block - or even better some "validateable/predictable" data block - like a 1.000.000 times repeated pattern like 012345789).
if the global contains a custom type you could use its "Delete()"
SuperStrictIncbin "system.fmf" ' comment out this line to remove the bug explained belowIncbin "fade.png"SetGraphicsDriver D3D9Max2DDriver()Graphics(1024, 768, 0, 60)SetColor (255, 255, 255)DrawText ("load....", 3, 3) ' creates 5 textures -> 'l' 'o' 'a' 'd' '.'Global gfx_fade:TImage = LoadImage("incbin::fade.png", 0) ' load a TPixmap of size 1280x1024While Not KeyDown(KEY_ESCAPE) Cls ' CRASH HERE The bug occurs during the next steps: ' D3D9 code resizes the pixmap to 2048 x 1024 for power2 sizes. ' At the point of creating a new TPixmap all previous created textures ( ie 'l' 'o' 'a' 'd' '.' ) get freed. ' TMax2DImageFrame then creates the new texture at 2048x1024. ' When it tries to store the texture via _d3d9graphics.AutoRelease an EAV occurs at ' 'd3d9graphics.bmx -> TD3D9Graphics -> AutoRelease( unk:IUnknown_ ) -> _autoRelease.AddLast t' DrawImage(gfx_fade, 0, 0, 0) FlipWend
Maybe raise an issue on github for this?byeRon
Do not just rebuild the DX module - the change might affect more stuff (the change is there to make sure that globals are not garbage-collected). Once you have the newest BCC compiled with your _old_ brl/pub modules you can update brl/pub and recompile ALL of these modules (just rename old brl.mod and old pub.mod - so no "cached stuff" exists and it already compiles the modules needed).The problem with the modules was/is, that there are changes in the modules which are not understandable by old BCC. So you need a newer BCC to compile them - means you need to compile BCC with old modules first.Alternatively you can compile BCC with your vanilla BlitzMax and use this then.byeRon
Author
Topic: (FontMachine) 9MB Font fails to load in DX9 mode (Read 2496 times)
