silverio@brahms.berkeley.edu (C J Silverio) (11/24/89)
The good thing is that this is a simple question. The bad thing is, I don't know the answer. I wrote a nifty program on my Plus. Used Think C v4, ANSI library, very little Macish stuff at all. Runs just great. Never crashes. Runs fine under Multifinder/6.0.4. Takes up maybe 60K of memory. Didn't try heap scrambling yet. So I pop it on a Mac II and get an ID=01 in the same spot every time. 8 Megs, turned off all the inits, 6.0.3, turned off Multifinder, bomb bomb bomb same spot. Right while plonking a PICT into a window during the program start. The mac is all warmed up at this point -- all calls to InitThis and InitThat are made. My pal says "dollars to doughnuts it's an alignment problem." OK, cool, pretty easy to fix, right? Well, give me a pointer: Does Think C help fix this? Is there something I missed in the manuals? What To Do Now? Natch, I don't have a MacII hanging around to debug on -- I'll just have to borry one. Thanks as usual for your help...
tim@hoptoad.uucp (Tim Maroney) (11/25/89)
In article <1989Nov24.035604.27499@agate.berkeley.edu> silverio@brahms.berkeley.edu (C J Silverio) writes: >I wrote a nifty program on my Plus. Used Think C v4, ANSI library, >very little Macish stuff at all. Runs just great. Never crashes. Runs >fine under Multifinder/6.0.4. Takes up maybe 60K of memory. Didn't try >heap scrambling yet. > >So I pop it on a Mac II and get an ID=01 in the same spot every time. >8 Megs, turned off all the inits, 6.0.3, turned off Multifinder, bomb >bomb bomb same spot. Right while plonking a PICT into a window during >the program start. The mac is all warmed up at this point -- all calls >to InitThis and InitThat are made. > >My pal says "dollars to doughnuts it's an alignment problem." OK, >cool, pretty easy to fix, right? Dollars to doughnuts it isn't. The Plus uses a 68000, which is very nervous about alignment. The Mac II uses a 68020, which is much more relaxed. The 68020 can cope with pointers on pretty much any alignment, though I understand there's a bit of extra overhead for using unaligned pointers (something about an internal exception handler having to fire). If it ran on the Mac II but not on the Plus, then it would probably be an alignment problem, but not the other way around. Try heap scramble. That may bring it to the top if it's an unlocked handle problem. That would be my best bet. Are you perhaps doing something like (*x)->y = NewHandle(z), with x unlocked? I have seen things like this consistently succeed on one model and fail on another due to the different memory configurations. >Natch, I don't have a MacII hanging around to debug on -- I'll just >have to borry one. Try heap scramble on your Plus first. Oh, one more thing. You didn't mention whether the Mac II was a color machine. Since this happens during graphics, if the machine is color, it would change my best bet to that. Some fields of a grafport are not the same on a color system. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "The negro slaves of the South are the happiest, and, in some sense, the freest people in the world. The children and the aged and infirm work not at all, and yet have all the comforts and neccessaries of life provided for them." -- George Fitzhugh, CANNIBALS ALL! OR, SLAVES WITHOUT MASTERS, 1857
lsr@Apple.COM (Larry Rosenstein) (11/28/89)
In article <1989Nov24.035604.27499@agate.berkeley.edu> silverio@brahms.berkeley.edu (C J Silverio) writes: > My pal says "dollars to doughnuts it's an alignment problem." OK, > cool, pretty easy to fix, right? ID=01 is a Bus Error, which means you tried to access a non-existent address. It is impossible to get a Bus Error on a Mac Plus or SE, because the hardware wraps around addresses. On a Mac II, if you try to access the addresses assigned to a NuBus slot and no card exists there, you will be a Bus Error. An alignment problem, as you refer to it, would be an address error which is ID=02. On a 68000 yo ucan get an address error if you try to do a word or long operation but use an odd address. The 68020 can handle this case, however, at a cost in speed. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
silverio@brahms.berkeley.edu (C J Silverio) (11/29/89)
THANK YOU to Tim Maroney and Larry Rosenstein for their timely comments. I now understand the "alignment" problem quite well, and that my application was definitely not suffering from one. I am still very mystified about what was causing the crash, since I tested it originally on a MacII (regular) with 8Mb and single Finder and NO inits. (I also scanned for virii, of which there were NONE.) We suspect the motherboard of the MacII in question. This MacII has recently (I just found out) been having Clock Problems. Of course the service dude didn't find anything wrong with it. The next day, I tried the SAME COPY of the program on the same hard disk (ie. the one I hadn't bothered to chuck in the trash), and it worked fine. So I put on the Heap Scrambler full blast, and turned on several applications (Word with bkgd repage, etc) and could not crash it. I'll have to get Discipline next. SO I added a whole bunch more error checking code (at a 25% increase in code size, and a 1% or 2% reduction in speed) and shrugged my shoulders and delivered the puppy. What other stress testing techniques do people recommend? thanks for your help etc.