690841 - Use CrashSubmit.pruneSavedDumps after plugin crashes to limit number of pending minidumps

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Jim]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

My pending crash reports folder grows about 1 GB per month.  I average about 4 new entries per minute.  Sites like Amazon and CNN cause these errors.  Google doesn't seem to.  These accumulate even if I am away from the PC as long as the sites are open in tabs.


Actual results:

No observed effect on Firefox operation.

Report URL: https://crash-stats.mozilla.com/report/index/623c620d-0c1b-467d-94d5-612c02110930

Comment 1

[Mats Palmgren (inactive)]

From bp-623c620d-0c1b-467d-94d5-612c02110930
Process Type: plugin Version: Filename: npmozax.dll

Does the crashing stop if you update that plugin to the latest version?
or if that doesn't help - disable this plugin?  (don't forget to restart Firefox)

Comment 2

[Jim]

Problem solved!  Disabling npmozax.dll (Mozilla activex control and plugin support) fixed my problem. I also found I could force the errors to stop by disabling the plugin container in about:config.  Is there a newer version of npmozax? I couldn't find one.  My version is 1.0.0.4.  Thank you for the help.

Comment 3

[Mats Palmgren (inactive)]

I think it's a plugin to host ActiveX controls:
http://www.adamlock.com/mozilla/plugin.htm
It looks unmaintained to me.  I would recommend that you uninstall it.

Comment 4

[Mats Palmgren (inactive)]

Would be nice to have a limit for the disk space used for crash reports though.

Comment 5

[Jim]

I have uninstalled the plugin npmozax.dll and everything is working.  I agree that it would be a good idea to limit the pending crash reports folder size. I first discovered the problem in August using treesize.  At that time my pending file was over 3GB and contained almost 1 million files.  Thanks again for your help.

Comment 6

[Mats Palmgren (inactive)]

Thank you for reporting the problem.

Comment 7

[Mats Palmgren (inactive)]

I found bug 471054 which looks like it should have prevented this problem,
maybe it's not working in some cases?

Comment 8

[Jim]

FYI the date that the plugin (npmozax.dll) was installed in my PC was 12/05/2005.  I have been upgrading my original Firefox since then.

Comment 9

[(not currently active) Ted Mielczarek]

Mats: that bug is very similar. The code there runs in the crash reporter client, but this is just a plugin crash, so we never get to run it. I think there are probably two issues here, so we should spin one off into its own bug:
1) We don't clean up the pending crash reports folder if the browser never crashes. If you only have plugin crashes, they can build up indefinitely.
2) If you have a plugin that crashes incessantly, like npmozax.dll in this case, we should disable it instead of allowing it to run and crash continuously.

Comment 10

[Benjamin Smedberg]

This bug will be about applying the cleanup logic to plugin-specific crashes. Ted will file a separate one about the incessantly-crashing-plugin issue, since that will be easier to do after click-to-play plugin support lands.

Comment 11

[(not currently active) Ted Mielczarek]

Filed bug 691432 on that.

Comment 13

[(not currently active) Ted Mielczarek]

From my dupe:
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #0)
> bug 814086 added a CrashSubmit.pruneSavedDumps API that matches what the
> crash reporter client does for browser crashes. We don't currently have this
> behavior for plugin crashes, which means that they can pile up on disk. We
> should use this API after a plugin crash to limit the number of pending
> crashes.

Comment 15

[Gabriele Svelto [:gsvelto]]

Old minidumps are already being pruned if they're not submitted, marking this as fixed.