Closed Bug 226267 Opened 21 years ago Closed 21 years ago

autocomplete in location bar takes minutes on some letters starting a most used URL

Categories

(SeaMonkey :: Location Bar, defect)

Product:
SeaMonkey
Component:
Location Bar
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hhschwab, Unassigned)

Details

(Keywords: hang, regression)

Attachments

(1 file)

patch
3.47 KB, patch
darin.moz
: review+
blizzard
: superreview+
dbaron
: approval1.6b+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031119
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031119

tested with a fresh, new profile, no problem.
If I copy my 2 MB big history.dat into this profile, I can´t type after I typed
the letter h into the location bar in these cases:
h as in http://
www.h as in www.heise.de
wwwh or wwh is working.

I tested all letters of the alphabet, only h shows this behaviour.

This is a regression, 
as this is working with this new profile with BuildID 20031008,
but not working with BuildID 20031106 and current nightly, BuildID 2003111908.

There is a Mozillazine posting about this:
http://forums.mozillazine.org/viewtopic.php?p=269495

there was a suggestion about changes to regexp slowing down history.dat,
Im often at heise.de, using links like:
http://www.heise.de/foren/go.shtml?list=1&forum_id=7308
http://www.heise.de/foren/go.shtml?read=1&msg_id=4588190&forum_id=7308&showthread=1

Reproducible: Always

Steps to Reproduce:
1.create new profile, or use current profile with a big history.dat
2.if using new profile, copy big history.dat into it.
3.check autocomplete by typing www.a then 2 backspaces and next letter b and so on.

Actual Results:  
I hang on h, had to kill mozilla, others get various long delays

Expected Results:  
react, if not in a reasonable time, at least after 10 seconds.

Setting severity to major only, as others don´t get a hang at h
Would set it to critical at least, if everybody would be hanging starting to
type http://
regression, 
working 2003111709  --> failing 2003111809

browser doesn´t hang, but simply needs 2 minutes time to think about the letter
h, then the menu with suggestions comes up.
Keywords: regression
maybe somebody should find a better title for this bug, like:
entering the first letter of the name of your most seen pages delays history.

with h for heise it needed 2 minutes on my celeron 333, with b for bugzilla it
was about 10 seconds. Others are seeing this bug with s for slashdot.

the not-working BuildID 20031106 I mentioned in comment 0 was an inofficial
build from JF.
Severity: major → critical
Keywords: hang
I'm seeing it under Linux, so please adjust platform to All.
Summary definitely needs tweaking - I have 11Mb history file, and almost every
letter typed in location bar causes this freeze.

setting OS to ALL as it happens on Linux too, updating summary, was:
Letter h typed into location bar hangs, if starting letter as http, or www.h
Flags: blocking1.6b?
OS: Windows 98 → All
Summary: Letter h typed into location bar hangs, if starting letter as http, or www.h → typeahead in location bar takes minutes on some letters starting a most used URL
Brendan: Is it possible that your Regex change caused this ?

What regexp change?  I landed rogerl's big rewrite.  Does that checkin, on
2003/10/22 07:01:49 UTC, correlate with the first appearance of the symptom?

Anyone who can reproduce this under a debugger, or on a system like Linux with a
working pstack utility, try getting stack samples as the "hang" progresses.  If
they're all showing the main thread in the jsregexp.c code, then this is yet
another regression from rogerl's rewrite.

Act fast, 1.6b is baking.

/be
QA Contact: PhilSchwartau
> Does that checkin, on 2003/10/22 07:01:49 UTC, correlate ?

No, see comment #1, regressed between working 2003111709  --> failing 2003111809

Initially I saw it notworking on 20031106, an inofficial build, and then latest
nightly, 20031119. I filed the bug, as 1.6b was near, and I didn´t have time to
test more.
When I had time, I did some more tests. Latest October build 2003102804 didn´t
show the bug, first November build 2003111309 didn´t show it either.
I repeatedly tested 111709 and 111809 using the same profile & history, 
111709 was working, 111809 was failing.
The hang isn´t a hang, my Celeron 333 only needs two minutes (minutes) to wade
through 2 MB of history.dat, maybe, because I only have 96 MB of RAM on this
machine. I couldn´t test at work on a more current computer, as I didn´t have
the time to.

from kmikes posting in mozillazine:
http://forums.mozillazine.org/viewtopic.php?p=269963#269963

Checkins to module SeaMonkeyAll between 11/17/2003 06:00 and 11/18/2003 09:00 :
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F17%2F2003+06%3A00%3A00&maxdate=11%2F18%2F2003+09%3A00%3A00&cvsroot=%2Fcvsroot

maybe bug 225343 or a checkin without bugnumber:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/js/src&command=DIFF_FRAMESET&file=jslock.c&rev1=3.52&rev2=3.53&root=/cvsroot

diff shows, that "Also avoid locking an object owning a sealed scope." was
introduced into a condition.

if (CX_THREAD_IS_RUNNING_GC(cx) ||  
(SCOPE_IS_SEALED(scope) && scope->object == obj) ||
(scope->ownercx && ClaimScope(scope, cx))) {  
return obj->slots[slot]; 

the old version:
if ((scope->ownercx && ClaimScope(scope, cx)) || 
CX_THREAD_IS_RUNNING_GC(cx)) { 
return obj->slots[slot]; 

the old version did execute the function ClaimScope(),
the new version doesn´t, if CX_THREAD_IS_RUNNING_GC() returns true.



The jslock.c change wouldn't have this effect. It would speed up things,
possibly unsafely in MT JS embeddings, but not in SeaMonkey.

Can someone back out the patch for bug 225343 and see if that helps?

/be

It didn't seem to fix this problem but I rebuild only /mozilla/js but that
should be enough..

I see a 10sec delay for the letter "o" on an Athlon2400+ and I cleaned my history 
and location bar history 2 days ago.

Matti, do you mean you rebuilt js/src with the change to jsregexp.c backed out,
and it didn't help this bug?

/be
Sorry, my mistake.

I backed out the change to jsregexp.c with the patch in bug 225343, recompiled
mozilla/js and that didn't fix fix the problem for me.
could you please try to use correct terms? using the wrong ones set off red
flags for me.
Summary: typeahead in location bar takes minutes on some letters starting a most used URL → autocomplete in location bar takes minutes on some letters starting a most used URL
Someone get stack samples, then we'll be getting somewhere.

/be
This puts mozilla below dogfood level for me - setting blocking1.6b+.
Don't think that autocomplete is at fault, as I see similar hangs when
focusing textboxes and on expose redraw.
Flags: blocking1.6b? → blocking1.6b+
Stopping it in the debugger, the only thread that seems to be doing anything
is necko:

#0  0x00a572ba in poll () from /lib/i686/libc.so.6
#1  0x008b68ed in _pr_poll_with_poll (pds=0x8adaea0, npds=1, 
    timeout=4294967295)
    at /home/tor/src/mozilla/nsprpub/pr/src/pthreads/ptio.c:3887
#2  0x008b6bd9 in PR_Poll (pds=0x8adaea0, npds=1, timeout=4294967295)
    at /home/tor/src/mozilla/nsprpub/pr/src/pthreads/ptio.c:4289
#3  0x08608315 in nsSocketTransportService::Poll() (this=0x8adab48)
    at /home/tor/src/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:325
#4  0x08608c11 in nsSocketTransportService::Run() (this=0x8adab48)
    at /home/tor/src/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:527
#5  0x00ef781e in nsThread::Main(void*) (arg=0x8adb160)
    at /home/tor/src/mozilla/xpcom/threads/nsThread.cpp:118
#6  0x008b80d8 in _pt_root (arg=0x8adb1e0)
    at /home/tor/src/mozilla/nsprpub/pr/src/pthreads/ptthread.c:214
#7  0x00cfedb2 in pthread_start_thread () from /lib/i686/libpthread.so.0
#8  0x00cfef45 in pthread_start_thread_event () from /lib/i686/libpthread.so.0
#9  0x00a6035a in clone () from /lib/i686/libc.so.6
What are the other threads' stacks?

/be
(gdb) info threads
  5 Thread 49156 (LWP 19332)  0x003a98b6 in nanosleep ()
   from /lib/i686/libpthread.so.0
* 3 Thread 16386 (LWP 19330)  0x008422ba in poll () from /lib/i686/libc.so.6
  2 Thread 32769 (LWP 19329)  0x008422ba in poll () from /lib/i686/libc.so.6
  1 Thread 16384 (LWP 19306)  0x00844431 in select () from /lib/i686/libc.so.6
(gdb) thread 5
[Switching to thread 5 (Thread 49156 (LWP 19332))]#0  0x003a98b6 in nanosleep
    () from /lib/i686/libpthread.so.0
(gdb) where
#0  0x003a98b6 in nanosleep () from /lib/i686/libpthread.so.0
#1  0x00000001 in ?? ()
#2  0x003a5b4a in __pthread_timedsuspend_new () from /lib/i686/libpthread.so.0
(gdb) thread 3
[Switching to thread 3 (Thread 16386 (LWP 19330))]#0  0x008422ba in poll ()
   from /lib/i686/libc.so.6
(gdb) where
#0  0x008422ba in poll () from /lib/i686/libc.so.6
#1  0x0075a8ed in _pr_poll_with_poll (pds=0x90b21b8, npds=1, 
    timeout=4294967295)
    at /home/tor/src/mozilla/nsprpub/pr/src/pthreads/ptio.c:3887
#2  0x0075abd9 in PR_Poll (pds=0x90b21b8, npds=1, timeout=4294967295)
    at /home/tor/src/mozilla/nsprpub/pr/src/pthreads/ptio.c:4289
#3  0x03218315 in nsSocketTransportService::Poll() (this=0x90b1e60)
    at /home/tor/src/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:325
#4  0x03218c11 in nsSocketTransportService::Run() (this=0x90b1e60)
    at /home/tor/src/mozilla/netwerk/base/src/nsSocketTransportService2.cpp:527
#5  0x0105781e in nsThread::Main(void*) (arg=0x90b2478)
    at /home/tor/src/mozilla/xpcom/threads/nsThread.cpp:118
#6  0x0075c0d8 in _pt_root (arg=0x90b24f8)
    at /home/tor/src/mozilla/nsprpub/pr/src/pthreads/ptthread.c:214
#7  0x003a3db2 in pthread_start_thread () from /lib/i686/libpthread.so.0
#8  0x003a3f45 in pthread_start_thread_event () from /lib/i686/libpthread.so.0
#9  0x0084b35a in clone () from /lib/i686/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread 32769 (LWP 19329))]#0  0x008422ba in poll ()
   from /lib/i686/libc.so.6
(gdb) where
#0  0x008422ba in poll () from /lib/i686/libc.so.6
#1  0x003a2d1a in __pthread_manager () from /lib/i686/libpthread.so.0
#2  0x003a2fea in __pthread_manager_event () from /lib/i686/libpthread.so.0
#3  0x0084b35a in clone () from /lib/i686/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 16384 (LWP 19306))]#0  0x00844431 in select ()
   from /lib/i686/libc.so.6
(gdb) where
#0  0x00844431 in select () from /lib/i686/libc.so.6
#1  0x044bd13c in __JCR_LIST__ ()
   from /home/tor/mdebug/dist/bin/components/libwidget_gtk2.so
#2  0x096ccdb8 in ?? ()
#3  0xbfe47608 in ?? ()

Backing out the patch from bug 226405 (gtk2 clipboard change) fixes the long
UI pauses in my build.
Attached patch patch — — Splinter Review 
Note that a request has completed and exit the select loop, regardless of
whether the request returned any data.
Attachment #136253 - Flags: superreview?(blizzard)
Attachment #136253 - Flags: review?(darin)
Comment on attachment 136253 [details] [diff] [review]
patch

r=darin
Attachment #136253 - Flags: review?(darin) → review+
Attachment #136253 - Flags: superreview?(blizzard) → superreview+
Comment on attachment 136253 [details] [diff] [review]
patch

This would be great to get in for 1.6b, it fixes a pretty noticable regression.
Attachment #136253 - Flags: approval1.6b?
Um, the original report is w98, that patch is gtk2...
Setting default QA -
QA Contact: PhilSchwartau → general
Attachment #136253 - Flags: approval1.6b? → approval1.6b+
Well, this addresses tor's comment anyway.  I'll leave the bug open.
Comment on attachment 136253 [details] [diff] [review]
patch

Checked in.  Leaving bug open since original issue was reported on another
platform, and that is obviously not addressed.
Seems to be fixed for me on win2k
Broken in 2003111909, works for me in 2003112308
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031125

tested with a new program folder, a new profile and copied same history.dat into
the profile before testing in this sequence:
BuildID 2003111908: 5 sec delay
BuildID 2003112308: no delay
BuildID 2003111908: 5 sec delay
BuildID 2003112008: 5 sec delay
BuildID 2003112508: no delay
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Has this been checked with ldap also as I was seeing a major slowdown on email
address autocomplete with our ldap server at work
I'm seeing something weird with autocomplete. I tried this with a clean profile.
Build 2003120208 on Windows XP.

Type g in the address bar, the autocomplete menu appears. Try pressing one of
the arrows on the scrollbar, the menu disappears. 

Is it related? IMHO, this should be fixed for 1.6b, it's highly annoying let me say.
It could be only related if you see a short hang
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: