Closed
Bug 24260
Opened 26 years ago
Closed 26 years ago
[DOGFOOD] Copy text to clipboard, quit app, crash
Categories
(Core :: XUL, defect, P1)
Tracking
()
VERIFIED
FIXED
M14
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.
Updated•26 years ago
|
QA Contact: paulmac → elig
| Assignee | ||
Updated•26 years ago
|
Severity: blocker → critical
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M14
| Assignee | ||
Comment 1•26 years ago
|
||
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.
| Reporter | ||
Comment 2•26 years ago
|
||
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
| Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 4•26 years ago
|
||
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.
| Reporter | ||
Comment 5•26 years ago
|
||
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 :-)
Comment 6•25 years ago
|
||
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
| Reporter | ||
Comment 7•25 years ago
|
||
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.
Description
•