Some attempts at HTTP requests result in browser hanging (regression from Bug 976446 - Replace YARR with irregexp)

NEW
Unassigned

Status

SeaMonkey
General
--
critical
3 years ago
2 years ago

People

(Reporter: kevink9876543, Unassigned)

Tracking

({hang, regression})

Trunk
x86
Linux
hang, regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [STR in comment 6])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20140427 Firefox/24.0 PaleMoon/24.5.0 (Nightly/Aurora)
Build ID: 20140427154131

Steps to reproduce:

SeaMonkey 2.29a1 built from c-c rev 6c52a4703dcd / m-c rev 41a54c8add09

1) go to http://xfinity.comcast.net/
2) click "TV Listings" on the left
3) when that page is done loading, click "Change location" next to "TV Listings recommended by Comcast"

** or **

go to about:crashes and try to view an already-submitted crash report (one with "bp-" prefixing it).


Actual results:

SeaMonkey hangs.
Submitted several crash reports from killing the hung browser, including this:
http://crash-stats.mozilla.com/report/index/bp-06be5fee-90f4-4a81-b207-fb0282140519


Expected results:

The browser should not have hung, and the clicked link should have loaded.
(Reporter)

Comment 1

3 years ago
m-c rev 4e38abbbd329 : works

m-c rev f396da6ddff2 : doesn't work

Comment 2

3 years ago
> http://crash-stats.mozilla.com/report/index/bp-06be5fee-90f4-4a81-b207-fb0282140519
OK so this is a self build so the crash-stats server obviously doesn't have your symbols file. You could try attaching gdb to SeaMonkey and dumping a stack trace.

> m-c rev 4e38abbbd329 : works
http://hg.mozilla.org/mozilla-central/log?rev=4e38abbbd329

> m-c rev f396da6ddff2 : doesn't work
http://hg.mozilla.org/mozilla-central/log?rev=f396da6ddff2

So it's either
http://hg.mozilla.org/mozilla-central/rev/43acd23f5a98
Bug 976446 - Replace YARR with irregexp

OR
http://hg.mozilla.org/mozilla-central/rev/f396da6ddff2
No bug. Fix a tiny error in the JS shell's help message. rs=terrence.
DONTBUILD because it's a trivial string-only change.

What happens if you set the following pref to false?
javascript.options.native_regexp

http://hg.mozilla.org/mozilla-central/rev/43acd23f5a98#l66.12
(Reporter)

Comment 3

3 years ago
(In reply to Philip Chee from comment #2)
> > http://crash-stats.mozilla.com/report/index/bp-06be5fee-90f4-4a81-b207-fb0282140519
> OK so this is a self build so the crash-stats server obviously doesn't have
> your symbols file. You could try attaching gdb to SeaMonkey and dumping a
> stack trace.
What's gdb and how do I do that?

> What happens if you set the following pref to false?
> javascript.options.native_regexp
Nothing different.
(Reporter)

Comment 4

3 years ago
For the record, I just tried building from m-c rev 43acd23f5a98, and (as expected) it doesn't work.

Also, apparently I already have gdb on my Linux system, so I tried to use it, but the backtrace it gave me (using the "bt" command) was just a bunch of hexadecimal numbers each followed by "in ?? ()".  I'm guessing that's because gdb can't find the debug symbols - so where would they be located?  (I couldn't find documentation about that on MDN or anywhere else.)
(Reporter)

Comment 5

3 years ago
This bug is still present, and it's a showstopper for me testing nightlies.
I'm not techie enough to figure out or understand gdb and I'd like to see this bug fixed.  Could someone please provide or link to complete instructions for how to get the requested information?  (I'm building and running SeaMonkey nightly on 32-bit Ubuntu 12.04.)
(Reporter)

Comment 6

3 years ago
Got it!

STR from a clean profile:
1) install Stylish add-on from addons manager, restart
2) add the following style:

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document regexp("^https://(?:[0-9A-Za-z-]+\.)*startpage\.com/do/search(?:[?].*)?") {

#sponsored_container {
    background-color: #E9C9A5 !important;
}

}

name it "Startpage Ad Recolor", save
3) if the browser didn't hang already after step 2, follow STR from comment 0.

Is there something really wrong with that regexp that I'm missing?

Comment 7

3 years ago
OK, that (adding the steps from Comment 6 into the mix) did it.

I'll attach a (Nirsoft) WhatIsHang report.
Note that the crash report ...40528 is an older existing report, not something generated during the hang itself.
Also the "hang" uses 25% CPU (100% of 1 core).

Comment 8

3 years ago
Created attachment 8432242 [details]
WhatIsHang report.

Comment 9

3 years ago
therube: Does Firefox also have this problem?
Blocks: 976446
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Some attempts at HTTP requests result in browser hanging → Some attempts at HTTP requests result in browser hanging (regression from Bug 976446 - Replace YARR with irregexp)
Whiteboard: [STR in comment 6]

Comment 10

3 years ago
This might be Bug 1015677 - irregexp: hang without slow script dialog while executing regular expression
Keywords: hang, regression

Updated

3 years ago
Flags: needinfo?(bhackett1024)
Do you get any slow script dialog?  Does seamonkey have one?
Flags: needinfo?(bhackett1024)
(Reporter)

Comment 12

3 years ago
Actually I think that regexp is indeed malformed in that each "\" should really be "\\".  Rewriting it that way I can not reproduce this problem.  But either way the browser still shouldn't be hanging - people are not going to take that to mean they need extra backslashes in their regex string.

(In reply to Brian Hackett (:bhackett) from comment #11)
> Do you get any slow script dialog?
No.

> Does seamonkey have one?
Yes
Hmm, with the comment 6 steps it looks like we're able to interrupt the regexp execution here but the regexp is actually executing while we're trying to show the slow script dialog, and nsGlobalWindow::ShowSlowScriptDialog prevents those interrupts from doing anything by nulling out the runtime's interrupt callback.  This seems like a design problem with the slow script dialog; the ilooping regexp is a bug in irregexp but shouldn't be causing the browser to hang.  I don't know if comment 0 is the same thing, I can't reproduce the hang with those steps.
(Reporter)

Comment 14

3 years ago
(In reply to Brian Hackett (:bhackett) from comment #13)
> I don't know if comment 0 is the same thing, I can't reproduce
> the hang with those steps.
STR in comment 0 was with a profile that was copied over from an older SeaMonkey and already had Stylish and the user style mentioned in comment 6 installed.  So it is indeed the same thing.
(In reply to kevink9876543 from comment #4)
> For the record, I just tried building from m-c rev 43acd23f5a98, and (as
> expected) it doesn't work.
> 
> Also, apparently I already have gdb on my Linux system, so I tried to use
> it, but the backtrace it gave me (using the "bt" command) was just a bunch
> of hexadecimal numbers each followed by "in ?? ()".  I'm guessing that's
> because gdb can't find the debug symbols - so where would they be located? 
> (I couldn't find documentation about that on MDN or anywhere else.)

For gdb to be able to give names rather than hex offsets in the backtrace, the program must have been compiled with symbols and not stripped. There are mozconfig settings for that, wait a minuteā€¦ ah, the following might be relevant, but no warranty: it's been a long time since I've last compiled SeaMonkey:

# build with debugging symbols
export MOZ_DEBUG_SYMBOLS=1
export CFLAGS="-gdwarf-2"
export CXXFLAGS="-gdwarf-2"
ac_add_options --enable-debug-symbols=-gdwarf-2
ac_add_options --disable-install-strip
mk_add_options PROFILE_GEN_SCRIPT='$(PYTHON) @MOZ_OBJDIR@/_profile/pgo/profileserver.py'
# debug build
ac_add_options --disable-optimize --enable-debug

Comment 16

3 years ago
Bug 1077514 was fixed in Mozilla 36 => SeaMonkey 2.33
Bug 1015677 was fixed in Mozilla 32 => SeaMonkey 2.29

Kevin, any more browser hanging due to regexp?
Flags: needinfo?(kevink9876543)
(Reporter)

Comment 17

3 years ago
(In reply to Philip Chee from comment #16)
> Kevin, any more browser hanging due to regexp?
Following STR in comment 6 then clicking a link from about:crashes to an already submitted crash report, yes, it's still hanging in Nightly 20141229003001.

However, I can't reproduce using the Comcast site anymore.
Flags: needinfo?(kevink9876543)
Severity: normal → critical
You need to log in before you can comment on or make changes to this bug.