This crash appears as if osx choked trying to log an error (levels 0-3) while trying to free a block (4).
Your guess is likely close. The block being released is either damaged (the memory manager pointers trashed) or was already released. Look carefully at the use of memory blocks. Writing beyond the end of a block can destroy an adjacent, unrelated, innocent block. We call this "lighting the fuse" because the system will continue to run and all looks good until the system frees the block that was destroyed, then - BANG! Very, very nasty bug to squash because the actual crash happens at some time later than when the overwrite bug happened. If you have global memory blocks, the crash may not happen until quit. Check his system and console logs; these may contain other messages that did make it to the log. Ask these questions: How is the one user different from the others? Larger files? Runs for hours vs minutes? Uses a combination of features others haven't? Plays games/music/videos in the background? ad nauseum,..... the point is, something is different.... Good luck my friend! Gary On May 16, 2007, at 5:12 PM, Tom Benson wrote: > His machines and OS details? All I can tell is that he is running > OS X. > > On 17/05/2007, at 7:15 AM, Dennis Birch wrote: > >> Hi list, >> >> I've got a user experiencing problems on his machine with an RB app I >> created, and I'm seeing consistent output from his OS X crash reports >> (shown below, in part). But I'm not sure how to interpret it. My >> guess >> is that it has something to do with manipulating a MemoryBlock, as >> that is the main thing going on in my application's function >> identified by line 10 of the crash report output. But I thought I'd >> see if anybody on the list has knowledge or experience with this >> output to help me better isolate the problem. He is getting these >> crashes when he quits the application. Another possibly helpful >> tidbit >> is that this function is also called when the application starts up, >> but does not create any problems at that point apparently. >> >> Also, of a dozen beta testers, he is the only one experiencing >> crashes >> -- it appears I fixed an earlier one he was having when he quit the >> application. Does that point anybody on the list to the >> possibility of >> something to look for? >> >> Thread 0 Crashed: >> 0 libSystem.B.dylib 0x90003568 strlen + 8 >> 1 libSystem.B.dylib 0x90131468 _simple_vdprintf + 3688 >> 2 libSystem.B.dylib 0x90131ca8 _simple_dprintf + 52 >> 3 libSystem.B.dylib 0x9012c91c malloc_printf + 132 >> 4 libSystem.B.dylib 0x90007288 szone_free + 1628 >> 5 rbframework.dylib 0x01894d80 MemoryBlockFinalizer >> + 44 >> 6 >> 0x0001dec0 MemoryBlock.__Exit%%o<MemoryBlock> + 56 >> 7 rbframework.dylib 0x0187c854 ResolveWeakRef + 116 >> 8 rbframework.dylib 0x0187c1e8 RuntimeLockObject + 592 >> 9 rbframework.dylib 0x0187c294 RuntimeUnlockObject >> + 52 >> _______________________________________________ >> Unsubscribe or switch delivery mode: >> <http://www.realsoftware.com/support/listmanager/> >> >> Search the archives: >> <http://support.realsoftware.com/listarchives/lists.html> > > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives: > <http://support.realsoftware.com/listarchives/lists.html> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
