871249 - crash with many open tabs (due to pdf.js?)

Status: RESOLVED DUPLICATE of bug 881974

(Core :: JavaScript Engine, defect)

Description

[Manuela Muntean [Away]]

This bug was filed from the Socorro interface and is 
report bp-6f1b5c6b-99ef-4a9d-ba11-505052130512 .
============================================================= 

Reproducible with Firefox 21 RC build 3 - build ID: 20130511120803

Steps to reproduce:

1. Open 50 tabs, from which 4 are pinned containing and the others are: 1 Facebook tab, 1 Gmail tab, 1 Yahoo mail tab, 6 tabs with both Flash and Java games (wickedgoodgames.com), 1 Google Maps tab, 22 pdfs, 3 Google search tabs, 6 tabs with Flash content, 6 tabs with Silverlight content

2. Log into Facebook, Gmail, Yahoo mail, search a place in Google Maps and browse through the tabs.


Expected results:

The browsing should work smoothly.

Actual results:

After browsing through tabs, Firefox crashes with empty signature.


Notes:

1. Investigations regarding other branches and if the issue is a regression will be done as soon as possible.

2. This issue reproduces intermittently with Windows XP 32bit.

Comment 1

[Scoobidiver (away)]

The latest NVIDIA driver for GeForce GT 610 is 314.22, not 311.06. Oddly, Direct2D and Direct3D 10 are disabled. Do you use a new profile?

Do you use Classic or WebGL Google Maps?

We need a valid stack trace (see https://developer.mozilla.org/docs/How_to_get_a_stacktrace_with_WinDbg).

Comment 2

[Manuela Muntean [Away]]

(In reply to Scoobidiver from comment #1)
> The latest NVIDIA driver for GeForce GT 610 is 314.22, not 311.06. Oddly,
> Direct2D and Direct3D 10 are disabled. Do you use a new profile?

No, the profile isn't new. I have only 2 add-ons: Feedback and Skype Click to Call 6.8.0.12323, 12 bookmarks and pretty much history.

> 
> Do you use Classic or WebGL Google Maps?

Classic Google Maps
> 
> We need a valid stack trace (see
> https://developer.mozilla.org/docs/How_to_get_a_stacktrace_with_WinDbg).

Ok, I'll get on it as soon as possible.

Comment 3

[Manuela Muntean [Away]]

This issue is also reproducible with Firefox 20.0.1, but it isn't with Firefox 4, so it's a regression.

Comment 4

[u279076]

Manuela, please work on finding a narrower regression window asap. Thank you.

Comment 5

[Manuela Muntean [Away]]

Here are the results of my investigations:

1) - the issue reproduces with Firefox: 19.0.2, 18.0.2, 17.0.1 (but after crashig, I do get a signature: https://crash-stats.mozilla.com/report/index/bp-68a30c2c-d105-4136-8ad6-b73f52130513 ; considering I followed the same steps, I think it's the same issue), 16.0.2 and 15.0.1

2) - I've noticed that the crash occurs after I stress test one ore more .pdf files: I browse through pages, zoom in/out, fullscreen (in most cases, after a fullscreen and switching to a .pdf file from a new tab, the crash occurs)

3) - with Firefox 14.0.2, I can't reproduce the issue anymore (even if I set "pdfjs.disabled" to false in "about:config", I can't see the .pdf file inline)

So, I think that the regression is between Firefox 14 and 15.

Comment 6

[Andrew McCreight [:mccr8]]

It sounds more like this is a problem with pdf.js than an actual regression.  We've seen very high memory usage with pdf.js before, and you have a lot of them open at once, so I could imagine there's some kind of OOM crash.

Comment 7

[Tracy Walker [:tracy]]

This is top crash #2 on 24, #4 on Aurora and #9 on Nightly

Comment 8

[u279076]

(In reply to Andrew McCreight [:mccr8] from comment #6)
> It sounds more like this is a problem with pdf.js than an actual regression.

Is there any specific action we can take in this bug to improve this situation apart from generally trying to improve PDF.js memory usage? If not I question whether we should leave this bug open.

Comment 9

[Andrew McCreight [:mccr8]]

(In reply to Tracy Walker [:tracy] from comment #7)
> This is top crash #2 on 24, #4 on Aurora and #9 on Nightly

Well, now the signature is just the generic GC crash, so it is going to get all sorts of things bucketed in that probably don't have anything to do with the steps to reproduce in comment 0, like hardware failures.

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #8)
> Is there any specific action we can take in this bug to improve this
> situation apart from generally trying to improve PDF.js memory usage? If not
> I question whether we should leave this bug open.

Not as far as I can tell.  I think the best thing to do is just to dupe this to bug 881974, which is a generic bug about pdf.js using a lot of memory.  Although, comment 0 says they were using the Skype Click To Call addon, which is known to have memory leak problems (bug 911650), so I guess it could be that. I'm not sure if this was reproducible without the addon.

Comment 10

[u279076]

Thanks Andrew.

Tracy, can you confirm that your steps to reproduce this work without the Skype add-on?

Comment 11

[Tracy Walker [:tracy]]

Anthony, I did not have the Skype add-on when doing testing around bug 881634. (load the large PDF in 10 tabs).

Manuela, can you reproduce this without the Skype add-on?  If so, this bug and bug 881974 are duplicates. If not, then this bug is probably a dupe of bug 911650.

Comment 12

[Manuela Muntean [Away]]

(In reply to Tracy Walker [:tracy] from comment #11)
> Anthony, I did not have the Skype add-on when doing testing around bug
> 881634. (load the large PDF in 10 tabs).
> 
> Manuela, can you reproduce this without the Skype add-on?  If so, this bug
> and bug 881974 are duplicates. If not, then this bug is probably a dupe of
> bug 911650.

I've managed to reproduce this crash with the steps from comment 0, on Win XP 32bit, with Firefox 21 RC build 3 and without any add-ons.

Here is the crash report: https://crash-stats.mozilla.com/report/index/871f5520-6a52-449f-a5a1-0f2e82130913

Comment 13

[u279076]

Thanks Manuela,

I'm duping this to bug 881974 for now. Feel free to undo that if you think this deserves it's own bug report.