Closed Bug 24260 Opened 25 years ago Closed 25 years ago

[DOGFOOD] Copy text to clipboard, quit app, crash

Categories

(Core :: XUL, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: phil, Assigned: mikepinkerton)

Details

(Whiteboard: [PDT+])

1. Launch apprunner
2. Copy text from URL bar
3. Exit the app
4. Hits assertion failure, followed by crash:

_free_dbg_lk(void * 0x023c75a0, int 0x00000001) line 1050 + 82 bytes
_free_dbg(void * 0x023c75a0, int 0x00000001) line 1001 + 13 bytes
free(void * 0x023c75a0) line 956 + 11 bytes
PL_strfree(char * 0x023c75a0) line 44 + 10 bytes
nsCRT::free(char * 0x023c75a0) line 167 + 9 bytes
nsClipboard::ForceDataToClipboard(nsClipboard * const 0x02df5bb0) line 694 + 10
bytes
main(int 0x00000001, char * * 0x00bf3330) line 721
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1ba06()

"data" is filled with 0xDD, so it has already been freed.

I'm calling this a blocker since I use the clipboard a lot, and this makes the
product pretty hard to use.
QA Contact: paulmac → elig
Severity: blocker → critical
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M14
Hrm, i haven't seen this myself, but i trust you. Yup, this sucks. Will try to
fix today, but marking m14 just to appease the higher ups that don't want to see
m13 bugs.

downgrading to critical, this doesn't really block anything, does it?

removing rod from cc list. he doesn't do clipboard anymore. no need to hassle
him.
Well, it's a blocker in the sense that any time you use the clipboard (as far as
I can tell) you're destined to crash when you quit. If that doesn't sound like a
blocker to you, I can live with critical.

Sorry to have pestered rods. I was going by the cvs log on nsClipboard.cpp
Whiteboard: [PDT+]
Putting on PDT+ radar.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed. I didn't totally ifdef out all vestiges of AOLMAIL from the converter.

btw, i think that 0xDD is uninitialized memory, since that is what we were
actually dealing with in this bug. 0xEF is freed memory.

sorry about the regression.
Thanks for fixing it. With respect to what 0xDD means, the VC6 runtime library
source code says:

static unsigned char _bNoMansLandFill = 0xFD; /* fill no-man's land with this */
static unsigned char _bDeadLandFill   = 0xDD; /* fill free objects with this */
static unsigned char _bCleanLandFill  = 0xCD; /* fill new objects with this */

It wouldn't surprise me if they'd changed this over time. I vaguely remember
that 0xFEEE used to be freed memory in VC4, and it's kind of onomatopoeic :-)
I can't reproduce this on any of the 2000012[7|8]08 builds (on Win32/Linux/Mac 
OS]. 

Verifying as FIXED.

Phil --- could you possibly give this a quick check when you have a moment? (I 
never saw this bug, and would like to be sure there isn't a Secret Missing Step.)
Status: RESOLVED → VERIFIED
I don't have an up-to-date debug build, but this works fine now using
2000-01-31-11 on Windows NT.
You need to log in before you can comment on or make changes to this bug.