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. On 6/2/06, Bad_Wolf <[EMAIL PROTECTED]> wrote:
Hi Peter, I read your email about your problem. I agree that this situation is very frustrating. And someone from RealSoftware should have addressed it by now. Try to describe in detail when those random errors occur and when they occur which sections of your program they occur. I do not know much of the Realsoftware people. But the one I was in contact with in the past, where all very helpfull. The one I find most helpfull is Aaron Ballman and his email is "[EMAIL PROTECTED]". If I where you, I should try him, if he can he will surely help you. Another possibility is using one of the RealBasic forums. You have RealSoftware forum at : http://forums.realsoftware.com/ Or you can visit the Realgurus forum at : http://realgurus.com/board/ There are so many very little things which go wrong in an application. When I read your problem, I think there is a conflict somewhere between your code and another program or extension. Did you try out your compiled application on another platform? Maybe you can try your program on Windows and running it with minimal extensions (protected mode). See how it behaves then. Needles to say that in this mode your program has little options coming from the system. Also you can shut off as many extensions possible. You try your program. When it is working fine, activate one extension again and try your program again. When it is working fine continue this process. In this way you find out maybe where the conflict is. Also trying our your application inside the RealBasic IDE is completely different than running it as a stand alone program. I was guessing here and after looking to your former post, I think you already tried all this. I am sure you are an experienced programmer. Therefore contact Realsoftware. When they do not respond, phone them directly until you get an satisfying answer. It should be pitty that you loose two months of hard work for such difficult errors. In my opinion Realsoftware has also a responsibility here and they should reply anyway to you. So if anyone of RealSoftware reads this, I can only give them one advice for good public relations; reply to this problem and make sure this problem is solved. I wish you a very nice day and all the best! I hope your problem will be solved very soon. Friendly greetings, Bad_Wolf Peter K. Stys wrote: > the problem with upgrading and trying for yourself is this: you'll do > fine with simple projects while getting the feel for the new compiler, > and in fact I very much like the look-and-feel of RB2006. Then you > settle in for a big job, and you find more and more minor irritants > like GUI quirks, and major problems like random (but all too frequent) > application crashes. I've been chasing a random crash in one of my fn > calls for 2 months now, and really don't think it's my fault (I posted > a msg recently with no reply, no surprise, how does one help out with > a random memory fault exception). If I don't fix the problem, my app > is dead in the water, and my only consolation is that I don't make a > living from it. > > I am once again looking at moving to Xcode for good, but keep coming > back to RB because of its simplicity. But if I spend 2 months chasing > 1 bug unsuccessfully, then one day the balance will be tipped and I > will have to make the (huge) jump to another dev tool. > > What will happen when the compiler moves to Universal and Cocoa? I > sympathize with RS and am sure they're making every effort, but at the > end of the day, I chase many bugs that are not mine, instead of being > productive. > > The love-hate relationship continues unfortunately.... > > Peter. > > _______________________________________________ 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>
-- ------------------------------------------------------------------------------- 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>
