overwriting memory (ABR in nsStdUrl::SetSpec)

VERIFIED WORKSFORME

Status

--
critical
VERIFIED WORKSFORME
18 years ago
11 years ago

People

(Reporter: Brade, Assigned: alecf)

Tracking

({crash})

Trunk
x86
Windows NT
crash

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
I see an overwrite problem on both Macintosh and Windows (Purify):
  [E] ABR: Array bounds read in nsStdURL::SetSpec(char const*) {16 occurrences}
error location:
      nsStdURL::SetSpec(char const*) [nsStdURL.cpp:869]
   =>     while (midPtr && (*midPtr != '\0')) {

The memory was allocated just above (line 855)
 =>     nsresult rv = DupString(&eSpec,i_Spec);


I discovered this while trying to reproduce a bug assigned to me.
To reproduce:
  (possibly can be pared down)
  load a page in browser (which contains links)
  select the url
  press delete
  choose Edit | Undo
  choose Edit | Redo
     [at this point you don't have any text in the urlbar]
  drag an url from the page into the urlbar
     [url should appear in urlbar]
  choose Edit | Undo
  choose Edit | Redo


Let me know if you need more info from Purify.
(Reporter)

Comment 1

18 years ago
two other ABR's from Purify include these lines (870, 876):
 =>         while ((*midPtr == '\r') || (*midPtr == '\n')) { // if linebreak

 =>             *copyToPtr = *midPtr;
Target Milestone: --- → mozilla0.9.1

Comment 2

18 years ago
I put some printfs in SetSpec and then followed the steps above exactly and got
a bogus pointer passed in to SetSpec.  The printfs printed out some random data,
then - crash!  I think one of the callers is doing something bad here...  I'll
try to figure out who, but given the number of times SetSpec is called...  :o
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9

Comment 3

18 years ago
Oh, duh - stack might help.  Looks like the offender may be nsUrlbarHistory:

PL_strfree(char * 0x0647cab0) line 44 + 10 bytes
nsCRT::free(char * 0x0647cab0) line 180 + 9 bytes
nsStdURL::SetSpec(nsStdURL * const 0x0647b150, const char * 0x0012e0a4) line 908
+ 16 bytes
nsUrlbarHistory::GetHostIndex(nsUrlbarHistory * const 0x0546f100, const unsigned
short * 0x0647caf0, int * 0x0012e5f4) line 558 + 72 bytes
nsUrlbarHistory::SearchCache(nsUrlbarHistory * const 0x0546f100, const unsigned
short * 0x0647caf0, nsIAutoCompleteResults * 0x0647b230) line 397
nsUrlbarHistory::OnStartLookup(nsUrlbarHistory * const 0x0546f104, const
unsigned short * 0x0647caf0, nsIAutoCompleteResults * 0x064aaab0,
nsIAutoCompleteListener * 0x0647b2d0) line 276 + 29 bytes
XPTC_InvokeByIndex(nsISupports * 0x0546f104, unsigned int 3, unsigned int 3,
nsXPTCVariant * 0x0012e8c8) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x03a8e5f0,
nsXPCWrappedNative * 0x05471de0, const XPCNativeMemberDescriptor * 0x0547056c,
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 3, long *
0x013baf04, long * 0x0012eab0) line 934 + 42 bytes
WrappedNative_CallMethod(JSContext * 0x03a8e5f0, JSObject * 0x01285368, unsigned
int 3, long * 0x013baf04, long * 0x0012eab0) line 250 + 34 bytes
js_Invoke(JSContext * 0x03a8e5f0, unsigned int 3, unsigned int 0) line 786 + 23
bytes
js_Interpret(JSContext * 0x03a8e5f0, long * 0x0012f830) line 2679 + 15 bytes
js_Invoke(JSContext * 0x03a8e5f0, unsigned int 3, unsigned int 2) line 803 + 13
bytes
js_InternalInvoke(JSContext * 0x03a8e5f0, JSObject * 0x01215cf8, long 19420360,
unsigned int 0, unsigned int 3, long * 0x06478470, long * 0x0012f958) line 875 +
20 bytes
JS_CallFunctionValue(JSContext * 0x03a8e5f0, JSObject * 0x01215cf8, long
19420360, unsigned int 3, long * 0x06478470, long * 0x0012f958) line 3340 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x03a8e7a0, void * 0x01215cf8,
void * 0x012854c8, unsigned int 3, void * 0x06478470, int * 0x0012f9f0, int 0)
line 940 + 33 bytes
GlobalWindowImpl::RunTimeout(nsTimeoutImpl * 0x0647cba0) line 3286 + 84 bytes
nsGlobalWindow_RunTimeout(nsITimer * 0x0647cb40, void * 0x0647cba0) line 3549 +
15 bytes
nsTimer::Fire() line 194 + 17 bytes
FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 4933, unsigned
long 214609922) line 78
USER32! 77e712a4()
nsAppShellService::Run(nsAppShellService * const 0x00b77750) line 408
main1(int 1, char * * 0x00a94650, nsISupports * 0x00000000) line 1021 + 32 bytes
main(int 1, char * * 0x00a94650) line 1316 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1ba3c
Component: Networking → URL Bar

Comment 4

18 years ago
Okay, tracing the pointer up the stack, I entered into js land - looks like the
bad value is coming either from JS or some scary XPC/XPTC stuff...  :)  Handing
off to the local URLBar guru...

Adding keyword crash since it crashed for me!
Assignee: pollmann → alecf
Status: ASSIGNED → NEW
Keywords: crash
QA Contact: tever → claudius
Target Milestone: mozilla0.9 → ---
(Assignee)

Comment 5

18 years ago
argh. I could use some help figuring out who is calling setSpec with a bad
string! I have a feeling this is editor related, because raw JS by itself it not
going to generate bad strings....it could be nsUrlbarHistory junk though
Status: NEW → ASSIGNED

Comment 6

18 years ago
nav triage team:

Can't reproduce using my 05/01 mac build. Kathy, do you still see this with a 
current build?
(Assignee)

Comment 7

18 years ago
marking WORKSFORME unless we get another reproducable case
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 8

18 years ago
This bug can't be verified right now because drag and drop seems to be broken.  
:-(
mass-verifying WorksForMe bugs which haven't changed since 2001.12.31.

set your search string in mail to "EmperorLondoMollari" to filter out these
messages.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.