FastExtension Memory Leak
Blitz3D Forums/Blitz3D Programming/FastExtension Memory Leak
| ||
| There is a very serious issue going on with "GetBrushTexture" when using FastExt; apparently, the library is using a nameless null texture that is always returned by the aforementioned function. GetBrushTexture() on raw native Blitz3d returns no texture handle on a textureless entity, which is contrary to the behavior seen when using FastExt: textureless entities always return some sort of null texture handle that holds it's memory space, but cannot be freed after using GetBrushTexture (attempt to do so ends up in unexplained Memory Access Violation). The "null" texture returned by GetBrushTexture appears to be an everchanging integer handle when this happens. I am running code that checks if entities have textures for analysis, which requires the use of GetBrushTexture. As we all know, the native behavior of this function is to actually return an instance/copy of the texture and not the texture itself. FastExt, regardless, returns the very null texture (or whatever it is...) and apparently when you try to free it, which is the common procedure after using GetBrushTexture if you are not saving that texture anywhere, the library causes a global crash. I am using the latest FastExtension lib. Sent an email to the maker of the lib in case he doesn't frequent this place. |
| ||
| About the memory leak: inability to erase the texture returned by this function, when using this lib, causes the leak. GetBrushTexture keeps creating copies/instances of this mysterious texture, which is what really breaks the thing. |
| ||
| looks like the forums had a hiccup and some posts were deleted...? anyways, here is a code sample: Include "include\FastExt.bb" ; enable or disable this line to switch between classic Blitz3D or FastExt Graphics3D 800,600,32,2 InitExt% () ; enable or disable this line to switch between classic Blitz3D or FastExt Global Cube=CreateCube() Global C Global Surf Global Brush Global T Global Texture For C=1 To CountSurfaces(Cube) Surf=GetSurface(Cube,C) Brush=GetSurfaceBrush(Surf) For T=0 To 7 Texture=GetBrushTexture(Brush,T) If Texture<>0 DebugLog "Texture integer address on layer "+(T+1)+": "+Texture+" / Texture name: "+TextureName(Texture) Else DebugLog "No texture found on layer "+(T+1) EndIf ; this is where FastExt fails FreeTexture Texture DebugLog "Aforementioned texture instance deleted after check." DebugLog "" ;__________ Next FreeBrush Brush Next Really really need this issue solved; I am very dependant on getbrushtexture() and don't want to rid the FastExt from my project :( BTW; Blitz3D also returns a mysterious nameless texture without this lib, but at least you can free it without a memory access violation, after retrieval. In essence, it sounds like something that could be fixed on either end; what's the point of returning a texture handle when there really is no texture to return from a textureless entity? Last edited 2012 |
| ||
| My inside source pixies tell me that GetBrushTexture was designed with the assumption that getting the texture from an untextured brush should raise an error. This does not help you in any way (and isn't even relevant if the engine as-provided has no problem with it), but it feels like something that ought to be pointed out for the sake of completeness. Are you sure that it is a texture handle that FastExt returns, and not just a junk pointer? What indicates that it is a texture if texture operations are invalid? 'Cause if it's junk, then the explanation for the behaviour is pretty straightforward. Combined with the above observation, it seems like Mikhail was just a little less careful than Mark in providing "safe" null values where there's a risk of running into something that doesn't exist. Last edited 2012 |
| ||
| My code sample pretty much explains it; I am creating a cube on the fly, supposedly without any textures. Blitz3D (native) returns a pointer to a texture on every brush layer even if they are empty; you can free the pointer by using "freetexture". I guess this is not really the fault of FastExt, but there must be a reason why freeing that junk pointer in native blitz gives no issue, while with the lib it totally does. I am guessing that if you attempt to do anything with that junk pointer, on native blitz3d, you will get further errors. I managed to solve the issue by hacking the wrapper/include file and editing the "GetBrushTexture" entry so you are given the option to use the old native command if this "nameless texture of mystery" issue arises. I still don't like the solution as it ignores the intended function replacement for the whole lib and is bound to leave some more leaks on the mirrored FastExt end. Last edited 2012 |
| ||
| I only get a MAV with that code sample if I run it with the fastext.bb included and the init function for fastext commented out (which is expected behavior). With both the include line and the init line commented out it runs fine (as expected) and with both uncommented it also works fine. I'm also not seeing yet any signs of a memory leak tho need further testing to be sure. EDIT: Unless I'm missing something obvious FastExt is returning the same pointer on my PCs and I'm not getting any crashes I'm wondering if its something specific to your setup. Last edited 2012 |
| ||
| That's really bothering me then... I am on an old setup, but this behavior was already happening on a quite modern setup as well. I will do some research. Either way, it's something that should not be happening differently on different setups. |
| ||
| I may be entirely missing the point of what your explaining but the sample code you provided isn't showing the symptoms I _think_ your describing on either of my main PCs. |
| ||
| My code sample, as is, should be giving a MAV when it tries to free that texture. I am starting to wonder if I am having this issue thanks to keeping a slightly older version of blitz3D (I am on 1.101 for a reason I forgot) |
| ||
| okay, I think I found the reason: ***** V1.104 ***** Fixed a bug that was causing TextureBuffer to crash with default 'null' textures. This sounds a lot like the issue I'm experiencing, and having stayed with 1.101 for a long time now, it makes some sense. I will test with the latest version now. EDIT I was using both an old version of FastExt and Blitz3D. The answer to all this appears to be that I simply need to upgrade. I recall needing to stay with an older Blitz3D version some time ago when Terabit Packer would no longer work with anything above 1.101 for some reason. Last edited 2012 |
| ||
| Problem solved; It was all this time my own fault, which was about using an outdated version of blitz3D and Fastext combined. Ignore this thread and banish it from existence :( |
   |