Closed
Bug 24260
Opened 25 years ago
Closed 25 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•25 years ago
|
QA Contact: paulmac → elig
Assignee | ||
Updated•25 years ago
|
Severity: blocker → critical
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M14
Assignee | ||
Comment 1•25 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•25 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•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 4•25 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•25 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
•