Closed Bug 2198 Opened 26 years ago Closed 26 years ago

About 30% more bugs appear on optimized build than on debug build

Categories

(Core Graveyard :: Viewer App, defect, P1)

PowerPC
Mac System 8.5

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: elig, Assigned: saari)

Details

* TITLE/SUMMARY About 30% more bugs appear on optimized build than on debug build Per sdagley's request, I'm writing this up for your respective convenience to go through these and identify a root cause factor resulting in crashers occuring uniquely on optimized builds. * GENERAL FOO The bugs I've aware of that occur on the optimized build --- but don't occur on the debug build --- are: 1. 2158, "[PP] Mac Viewer crashes upon resizing" 2. 2160, "[PP] Repeatedly clicking around the URL window crashes Mac Viewer" 3. 2196, "[PP] Viewer suicides after 10 seconds if URL text left selected" * REGRESSION - Occurs On viewer (1.5.98 build for Mac OS) - Doesn't Occur On viewer (1.5.98 build for Win32) viewerDebug (1.4.98 build for Mac OS from sdagley) * CONFIGURATIONS TESTED - PowerMac 8500/150 (233 Mhz 604e), 64 MB RAM, Mac OS 8.5.1
BTW...if the bugs-that-occur-just-on-the-optimized-builds listed are insufficient for your needs, let me know --- there are a bunch more, particularly around the Find command, but I haven't written them up (since, well, they only occur on the optimized builds. ;)
2158 seems to be unrelated to resizing the window since I can resize it for a while before the crash happens. When it does finally crash (waaaay down in the bowels of the memory manager), it's trying to dispose a region in SetFont. Sounds to be like layout is trashing memory somewhere, and resizing really excercises layout.
See bugs 2193 and 2194 as well.
Assignee: sdagley → saari
Giving to Chris for a looksee
since the recent revelation about the optimized viewer's memory partition being 1600K, I upped it tp 10MB and at least one of the problems (app suicide when text selected in location field) went away!
More bugs in optimized builds than in debug builds? That's because the freed blocks are no longer filled with 0xEFEF in debug builds. Simon will restore the code very soon. I'm sure we can mark this bug "Fixed" as soon as he checks in ;-)
Actually, the memory allocators don't fill free blocks now at all, in either debug or optimized mode. But they will, in debug mode, soon.
I know... that's what I meant. Stupid humor, sorry. In fact, don't mark the bug fixed when the code get there: just turn the title around.
Setting all current Open Critical and Major to M3
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
This problem is no longer taking place. Specifically, in the past few weeks, neither pinkerton nor saari have recently encountered bugs that proved to be irreproducible on debug builds, and which QA has wrote up and could continue to reproduce on optimized builds. Thus, marked as verified/fixed.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.