MT Memory issues (GC?)
Archives Forums/BlitzMax Bug Reports/MT Memory issues (GC?)
| ||
| See thread at http://www.blitzbasic.com/Community/posts.php?topic=91075 for further details and some sample code. First off I never had any of these problems before I converted my project to MT, but I converted it because I NEEDED multithreading for a specific feature that's critical so I can't go back now. I can't get it to manifest the same in the test example as in my program. But it seems memory blocks can get juggled at unexpected times, causing large reads to fail and crash (e.g. when doing a TPixmap.Convert() it will crash while iterating through the pixels sometimes...) However it manifests differently in the example posted in the thread. Further more using some other modules (freeimage from Brucy specifically) I'll get a spinlock while a module tries to free some memory, and the main thread locks up waiting for a semaphore (I assume related to a memory clear, it usually comes from the event que getting managed...). This happens when copies etc. are done in child threads or the main thread. I can't get any example I try to punch up to reproduce the same problems as any other examples (they also tend to crash or hang differently in debug vs normal build) but they all have problems when you start juggling chunks of data. I've been hacking away at the MT garbage collector to see if I can get any more details, but I can't get anything reliable. I have however made 2 modifications: First, I made the collect function return right away if the GC is suspended. It would return from manual collects, but it looked like auto collects would still get fired. Second, I made the auto collect when creating a new memory alloc always fire by removing the heap check, as some examples would just hemorage memory otherwise. I'm happy to try anything or provide as much sample code as possible. I can send my current main project with the pixmap.convert() specific crash to Blitz directly if so desired but it's under some copywrites etc. so I can't publicly release it. Any thoughts of stuff to try, or examples to test, or questions about the crashes etc. please don't hesitate, I'm spending all my time on this at the moment as I NEED to get it fixed. |
| ||
| Probably related to all of this, but I'm getting crashes on mac on occasion where a child thread will die, and it's trace just shows a ton of calls to "mark + 72" which I assume is referencing static void mark( void *p ) in blitz.mod/blitz_gc_ms.c line 256 It seems to me (bearing in mind that I still don't fully understand the structures and methodology behind the MT GC system) that mark is getting recursively called forever.. which shouldn't be possible since it's flagging before the recursive calls... either that or the block it's iterating through is getting shifted (like the pixmap convert blocks mentioned earlier) while it's iterating and therefore it's going off into some other part of memory, and trying to mark something and that's crashing... |
   |