FreeImage getpixmap releases in multithread
BlitzMax Forums/Brucey's Modules/FreeImage getpixmap releases in multithread
| ||
| It seems that getpixmap doesn't lock the pixmap memory so the garbage collector firing at the wrong time can cause bad things to happen. When I was running in single thread mode I wrapped my GetPixmap call with GCSuspend and GCResume to prevent it from getting collected. When I went to multithread that didn't work any more (I don't think it respects GCSuspend in child threads), but I put a Copy() at the end of the GetPixmap() so it would make a new pixmap in my TPixmap, and that seemed to work. With the newest SVN I'm finding that it is now sometimes crashing in the Copy() call which based on my previous experience implies that the pixmap is getting cleared by the GC while it is being copied... This is happening on mac specifically, haven't tested on windows yet. Where it crashes looks like this GCSuspend() local pixm:TPixmap = theFreeImage.GetPixmap().Copy() GCResume() this is happening in a child thread, and the relevent part of the crash log is Thread 2 Crashed: 0 libSystem.B.dylib 0xffff08a0 __memcpy + 256 1 Working APP 0x002b58cb brl_pixmap_CopyPixels + 48 2 Working APP 0x002b3f59 2 + 0 3 Working APP 0x00030d77 102 + 16 4 Working APP 0x000309ca bb_LoadFormattedTexture + 28 5 Working APP 0x0002e7a1 338 + 54 6 Working APP 0x0002f2a8 bb_ThreadedElementQualityToActiveLevel + 78 7 Working APP 0x0020438e _brl_threads_TThread__EntryStub + 54 8 Working APP 0x002c0fcf threadProc + 175 9 libSystem.B.dylib 0x9052ea19 _pthread_start + 345 10 libSystem.B.dylib 0x9052e89e thread_start + 34 |
   |