1226961 - Loading specific website in browser freezes the browser until we get to an out of memory crash (or until the unresponsive script is killed by the warning dialog)

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[mathieu.tarral]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36

Steps to reproduce:

1. Login with a LinkedIn account on https://fr.linkedin.com/
2. Search for some name in the search bar
3. Open the first profile listed in a new tab



Actual results:

Firefox freeze when trying to load the LinkedIn profile page, and a memory leak is eating the memory  until Firefox is killed by the OS.


Expected results:

The LinkedIn profile page should have been rendered without problems.

Comment 1

[mathieu.tarral]

Somme additional informations:
Platform: Fedora 23

I was able to reproduce the bug in both normal mode and safe mode (add-ons disabled), but I wasn't able to reproduce it with a clean profile, created with "firefox --profile /tmp/foo".

Also, the bug is only present on some specific LinkedIn profile pages, not all of them.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Can you provide a specific linkedIn URL on which you are seeing the issue? Aldo, while the issue is happening, can you open about: memory in a new tab, get a memory report, and then attach it to this bug? Thanks!

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Attachment: GDB backtraces

I discussed this over email with Mathieu; he provided me with a video that demonstrated the problem (not posted publicly for privacy reasons; contact him directly if you need it). It seems like there's a runaway script on the page that is allocating gobs of memory and hogging the main thread. This makes the browser nonresponsive and also causes the memory usage to climb while the script is running. Eventually the unresponsive script warning appears and allows him to kill the script, at which point things return to normal.

He was able to download debug symbols and attach gdb, and provided the attached backtraces. This confirms the above theory, and shows the main thread (thread 1) is somewhere in the regexp code, having being invoked by the JIT.

So most likely this is a poorly coded website, but it might also be hitting a bad edge case in our code, and should probably be investigated further by somebody who knows the JS/regexp code.

Comment 4

[Nicolas B. Pierron [:nbp]]

This seems to be an issue in the RegExp engine.

Comment 5

[Brian Hackett [Laid off!]]

The first two frames of thread 1 in that gdb backtrace are in trace logging code, and seem to indicate that trace logging is active.  Trace logging logs information about every regexp execution performed by a script, but doesn't log anything internal to regexp execution, so I think this is unlikely to be a regexp problem and more likely to be things working as intended vis a vis trace logger overhead.  Why is trace logging active in this backtrace?

Comment 6

[Nicolas B. Pierron [:nbp]]

Hannes, why is trace-logging active in this backtrace?
Do you have any idea what might be wrong?

Comment 7

[Hannes Verschore [:h4writer]]

This is strange! I can confirm from the backtrace that TraceLogger is active.
It would also explain the symptoms of "uses hogs of memory and degraded performance".

Since this is strange, since one has to invoke it:
TLFLAGS = XXX / TLOPTIONS = XXX

Question 1) Can you give me the environment flags firefox is running with?

Another way to invoke it, is to use:
var du = new Debugger();
du.setupTraceLoggerScriptCalls()
du.startTraceLogger();

Both seem quite hard to hit by accident, but possible.
@Kartikaya: can we find out, if the js code on the affected site potentially has "setupTraceLoggerScriptCalls" in its code

Comment 8

[mathieu.tarral]

I have the same profile since a while now, and it is possible that I 
enabled some debugging features and that I forgot about it.

=> How can i export my about:config and get only the configuration modified by the user ?

Also, I added the firefox env in the attached files.

Comment 9

[mathieu.tarral]

Attachment: Environement

Comment 10

[Hannes Verschore [:h4writer]]

(In reply to mathieu.tarral from comment #9)
> Created attachment 8691903 [details]
> Environement

Thanks. Seems the cause is not the environment.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

I was just relaying info from Mathieu; if you have further questions he should be able to answer them directly.

Comment 12

[Hannes Verschore [:h4writer]]

(In reply to mathieu.tarral from comment #8)
> I have the same profile since a while now, and it is possible that I 
> enabled some debugging features and that I forgot about it.
> 
> => How can i export my about:config and get only the configuration modified
> by the user ?

cat ~/.mozilla/firefox/PROFILE_FOLDER/prefs.js

Comment 13

[Hannes Verschore [:h4writer]]

- can you reproduce with a nightly?
https://nightly.mozilla.org/

Comment 14

[mathieu.tarral]

I uploaded my pref.js file and removed the following keys for privacy reasons :
- capability.policy.maonoscript.sites
- services.sync.*

I have just tried with the latest nightly build for Linux x64, firefox-45.0a1.en-US.linux-x86_64,
in safe mode, and the bug is still triggered, but thanks to Electrolysis the browser is not frozen anymore :D

Comment 15

[mathieu.tarral]

Attachment: pref.js

Comment 16

[Hannes Verschore [:h4writer]]

I'll make a try build that(In reply to mathieu.tarral from comment #14)
> I uploaded my pref.js file and removed the following keys for privacy
> reasons :
> - capability.policy.maonoscript.sites
> - services.sync.*
> 
> I have just tried with the latest nightly build for Linux x64,
> firefox-45.0a1.en-US.linux-x86_64,
> in safe mode, and the bug is still triggered, but thanks to Electrolysis the
> browser is not frozen anymore :D

Good that you can repro on nightly. I'm gonna try to create a try-build that with some extra debug statements in order to have a better understanding.

In the meantime, can you move the pref.js file to pref.js.bac or something and try to reproduce. (I.e. that will remove all your custom preferences.) That way we can determine if a line in that file is causing this. Though looking at the file, there is nothing worrisome.

Comment 17

[Hannes Verschore [:h4writer]]

Nexto what I said in comment 16. Can you try this build:
http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-f3ea02aa2a5784c0a8b872276b22c79e1cc198ea/try-linux64/

and try to replicate it. Even if you cannot replicate, please attach the output from the terminal, which I need to dig deeper into this issue. Thanks!

Comment 18

[mathieu.tarral]

I tried to reset my preferences by moving my prefs.js to prefs.js.bak, started firefox in safe mode and I was still able to trigger the bug.


I also tried your customized nighlty build, triggered the bug and uploaded the output.

Comment 19

[mathieu.tarral]

Attachment: firefox-45.0a1-debug-output.txt

Comment 20

[Hannes Verschore [:h4writer]]

Thanks! I can confirm tracelogger isn't the reason. (Relieve on my side ;) ).

I've started a new build that focuses on regexp issues. Upon completion I will provide the link and ask you to try to trigger it again. Again I'm interested in the console output. But first the build have to finish.

Comment 21

[Hannes Verschore [:h4writer]]

Hey Mathieu, can you run the following build:
http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-518ba3a483aa0cdf5156cc1723445028ee137adc/try-linux64/

and give me the console output again?

Comment 22

[mathieu.tarral]

I was able to trigger the bug once again.
The output given by your build was HUGE (260M) !
I had to compress it with XZ to have an uploadable file.

Comment 23

[mathieu.tarral]

Attachment: firefox-45.0a1.en-US.linux-x86_64-output2.tar.xz

Comment 24

[Hannes Verschore [:h4writer]]

Thanks! The log is very helpfull.

Some strangeness in your log:
1) All regexp go to the interpreter! The jits doesn't work here !?
2) The Regexp look jittable

This raises the question:
- Do we have a memory leak in our regexp interpreter?
- Why don't we JIT?

Gonna investigate the code and look where potentially bugs could be.

Comment 25

[Hannes Verschore [:h4writer]]

I looked a bit around, but couldn't really pinpoint where things would potentially go wrong.
As a result I created another build with some extra print debugs:
http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-cba68377c85f3826319b3147933573bdb5070c2d/try-linux64/

Can you run this and provide the data it spews? This time you don't need to trigger the bug. You only need to have at least 30 lines of output ;).

thanks!

Comment 26

[mathieu.tarral]

So, I just opened firefox nightly in safe-mode and captured the output, if that's what you wanted.

Comment 27

[mathieu.tarral]

Attachment: firefox-45.0a1.en-US.linux-x86_64-output3.txt

Comment 28

[Hannes Verschore [:h4writer]]

(In reply to mathieu.tarral from comment #26)
> So, I just opened firefox nightly in safe-mode and captured the output, if
> that's what you wanted.

Interestingly that didn't trigger the issue. Hmm. Can you try again but with trying to trigger the bug?

Comment 29

[mathieu.tarral]

Sure !
Here is the output.

Comment 30

[mathieu.tarral]

Attachment: firefox-45.0a1.en-US.linux-x86_64-output4.txt

Comment 31

[Hannes Verschore [:h4writer]]

(In reply to Hannes Verschore [:h4writer] from comment #21)
> Hey Mathieu, can you run the following build:
> http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-
> 518ba3a483aa0cdf5156cc1723445028ee137adc/try-linux64/
> 
> and give me the console output again?

I just noticed that you ran the build from 2 days ago in safe-mode.
That might have skewed the results and deductions I made from them. Can you run it again, but this time in normal mode?
http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-518ba3a483aa0cdf5156cc1723445028ee137adc/try-linux64/

Comment 32

[mathieu.tarral]

(In reply to Hannes Verschore [:h4writer] from comment #31)
> (In reply to Hannes Verschore [:h4writer] from comment #21)
> > Hey Mathieu, can you run the following build:
> > http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-
> > 518ba3a483aa0cdf5156cc1723445028ee137adc/try-linux64/
> > 
> > and give me the console output again?
> 
> I just noticed that you ran the build from 2 days ago in safe-mode.
> That might have skewed the results and deductions I made from them. Can you
> run it again, but this time in normal mode?
> http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-
> 518ba3a483aa0cdf5156cc1723445028ee137adc/try-linux64/

I compressed the new output log and uploaded it.

Comment 33

[mathieu.tarral]

Attachment: firefox-45.0a1.en-US.linux-x86_64-output5.tar.xz

Comment 34

[Hannes Verschore [:h4writer]]

Interesting. In both attachments we have a overuse of two regexps:

1013139 JSString* (0x7fe371a1df00) = Latin1Char * (0x7fe3785eb228) = "^-ms-"
1013141 JSString* (0x7fe371a1df80) = Latin1Char * (0x7fe3785eb240) = "-([\da-z])"

Looks related.
Would be cool to have a search engine that could search on this to find which snippet uses this

Comment 35

[Hannes Verschore [:h4writer]]

(In reply to Hannes Verschore [:h4writer] from comment #34)
> Interesting. In both attachments we have a overuse of two regexps:
> 
> 1013139 JSString* (0x7fe371a1df00) = Latin1Char * (0x7fe3785eb228) = "^-ms-"
> 1013141 JSString* (0x7fe371a1df80) = Latin1Char * (0x7fe3785eb240) =
> "-([\da-z])"
> 
> Looks related.
> Would be cool to have a search engine that could search on this to find
> which snippet uses this

Seems like jquery uses both.

Comment 36

[Robert G. Siebeck]

I'm also experiencing this bug with Firefox 46.

Comment 37

[jacky]

I'm getting this with Firefox 48.0a2. I can attach a stack trace of what I got and am willing to build + run patches from what I'm experiencing.

Comment 38

[jacky]

My trace is here: https://gist.githubusercontent.com/jalcine/6c7bf87633b28f64df63c4754b5a8a3d/raw/b5fa6a8671ce6a58b0f14a7421a9a35dc148682b/gistfile1.txt

Comment 39

[Pankaj]

following website are taking too much time and browser are very slow some time hanging or taking long time to response
below are

http://www.ahram.in
http://www.ahramenterprises.com,
http://digitalpankaj.com,
http://www.friendsmoda.com
http://www.pretaporterclothing.com,
http://www.atlasliving.com


pleasew fix the bug and other issue thanks

Comment 40

[Pankaj]

please check also 
http://www.atlasliving.in