crash in [AutoCompleteTextField performSearch]



Camino Graveyard
Location Bar & Autocomplete
13 years ago
13 years ago


(Reporter: Josh Aas, Assigned: Josh Aas)



Mac OS X



(2 attachments)



13 years ago
Thread 0 Crashed:
0   org.mozilla.navigator    	0x00026410 -[AutoCompleteTextField performSearch]
+ 0x78
1     	0x909f30e4 __NSFireTimer + 0x68
2 	0x901945f8 __CFRunLoopDoTimer + 0xf4
3 	0x90191958 __CFRunLoopRun + 0x5c8
4 	0x90195e6c CFRunLoopRunSpecific + 0x148

Comment 1

13 years ago
I have added some debug code to my build and I'll try to reproduce the problem.
I'm pretty sure we're just not nil checking mSearchString or searchString when
we should be.
Target Milestone: --- → Camino0.9
I just had the same thing, seemingly at random (I was on, perhaps just hitting
return to leave, but definitely not just arriving, at )

Same exact log as Josh.

Comment 3

13 years ago
Created attachment 178938 [details] [diff] [review]
possible fix v1.0

There are only two places in performSearch that we might access bad memory. One
is mSearchString, the other is mSession. It pretty much can't be the former as
we set it to nil whenever we release. However, it is possible for mSession to
be nsnull, in which case calling functions on that address would be a bad
thing... I can't reproduce the crash (its just really hard to do it I think),
but this patch probably fixes it. I don't have time to look into it any more,
otherwise I'd make myself more sure about this solution before posting it.
Attachment #178938 - Flags: review?(sfraser_bugs)

Comment 4

13 years ago
Are you sure that the timer hasn't been left running when we should have shut it

Comment 5

13 years ago
I am not sure - like I said, I ran out of time for investigating things further.
I took a quick glance at the timing code before I made the patch and I didn't
see anything pop out at me, but I certainly did not do a thorough job of looking.

Comment 6

13 years ago
I got this crash two more times. Upping priority.
Severity: major → critical

Comment 7

13 years ago
Oh yeah - according to output from the debug code I added to my build,
searchString is getting assigned just fine and we are definitely crashing in the
following line due to an invalid mSession:

nsresult rv = mSession->OnStartLookup(searchString.get(), mResults, mListener);

Comment 8

13 years ago
Invalid, or null? If null, then r=sfraser on your patch.

Comment 9

13 years ago
IIRC, its null. Might it be worth waiting until we can figure out why the
session doesn't exist? If we go with this patch without further investigation,
we might have to deal with the problem again when another symptom pops up.

Comment 10

13 years ago
I've been running into this bug as well with recent Camino nightlies.  I'm
running Mac OS 10.3.8, with the most recent security update (which I suspect
might have had something to do with this crash, but who knows?).

Something else I've noticed:

   o When my DSL connection gets bumped off (I've got a bad filter on a phone
where I can't get to the freakin' jack), this crash pops up.

I'll attach the full crashlog, FWIW.  Good thing I searched before filing a new

Comment 11

13 years ago
Created attachment 179135 [details]
Crashlog from most recent crash

Forgot to mention Camino nightly version in comments, so here it is:  20050328.

Comment 12

13 years ago
I think we have enough crash logs and confirmations of the problem. They are all
exactly the same and we already know exactly where the problem is. Thanks.


13 years ago
Attachment #178938 - Flags: review?(sfraser_bugs) → review+

Comment 13

13 years ago
landed on trunk as we probably have better things to do now and this fix will be
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.