Just an update for the group. Some may recall my agony trying to chase down a random crash in my app (msg excerpted below): in a nutshell I kept getting frequent crashes in a single function during a m.ushort access. The memblock was malloc'd (reasons below). When I changed back to allocating via NewMemoryblock, after extensive use, no more crashes.
My conclusion: be careful with malloc in RB. For some reason, under certain rare circumstances, it will bite you. I wish I understood why. Aaron? Peter. On 6/7/06, Peter K. Stys <[EMAIL PROTECTED]> wrote:
I appreciate your thoughts. Unf. this is one of those "BAD" bugs that will be very tough to solve: - I run my built app (not IDE, which would just quit anyway or not cause the crash I suspect, see below) and insert debugging calls that send messages via AE's to a background sniffer app that logs them in memory (not disk, which would slow things down too much). I have a rolling log of the last 1000 or so debugging calls (I found this debugging method very convenient actually: you can make very frequent debugging calls without exploding a disk-based log file or slowing execution too much, when the target app crashes the sniffer holds the very last debugging msg (+999 previous ones that led to the crash) and your user emails you this dump). - inserting too many debugging calls in the offending method seemingly ELIMINATES the crashes, even more frustrating. - the crash always occurs while user mouses around his image and XY coords are passed to a method that returns the ushort value of the pixel under the cursor (not rocket science!). If-then tests have NEVER caught any out-of-bounds coords or bad memory addresses. Calling this same function a zillion times "artificially" from a test button with every possible XY combination NEVER crashed it, so the code in the method itself is sound. - Apple's crash log always reports a crash during a m.ushort access, seemingly an out-of-bounds pointer access (but it's never out of bounds AFAIK, at least not while I have control of it; what RB does with it deep within its framework I don't know). The memory block was malloc'd and not NewMemoryBlock'd (this may be the key, more later). - I doubt extensions are to blame, besides, under OS X it's supposed to be moot. - I can't compile for Windows because I use many Mac OS-specific calls in the app - This did not seem to be a problem with RB2005. - I've been writing code for 25 years, but "experienced" is relative: I have much to learn from folks on this list. However, in this case, I think I've tried everything I can to track this one down, and conclude it's a compiler problem. My lab is currently testing a version where the memblocks were NewMemoryBlock'd rather than malloc'd (which limits the max size of the block; see previous posts about a year ago on this, hence my decision to malloc). I'll let you know if it's a malloc issue (tho others have not reported problems; see recent posts from Charles I believe). It takes days to be sure because with random crashes like this, it becomes a statistical exercise before you can reach any conclusions. Triply frustrating. If Aaron reads this, perhaps he can think of how memblocks are treated/managed differently in RB2006, and if malloc vs. NewMemBlock would make a difference, and lead to crashes like this. Peter.
-- ------------------------------------------------------------------------------- Peter K. Stys, MD Professor of Medicine(Neurology), Senior Scientist Ottawa Health Research Institute, Div. of Neuroscience Ottawa Hospital / University of Ottawa Ontario, CANADA tel: (613)761-5444 fax: (613)761-5330 http://www.ohri.ca/profiles/stys.asp ------------------------------------------------------------------------------- _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
