Hi Sycho, if you've submitted crash reports where you included the URL of the page, can you check whether the URL is public? To view the public information, click a link on your about:crashes page. Thanks.

Unfortunately, jscher2000, I no longer have access to that computer as it was picked up by my client following repair/system recovery last night.

However, I do know that the file "Firefox Setup Stub 23.0.1.exe" installer on the download page was, pardon me, horrible.

Upon installation from a freshly recovered system, the browser crashed over a dozen times within a five minute time span. This not only occurred during loading the browser (with no "home page" set), but when visiting any web site or merely closing the browser down.

It took me several minutes (via searching) to locate "Firefox Setup 23.0.1.exe" from MajorGeeks. Upon successful installation, I no longer experienced those issues.

Mind you, the system was an Acer all-in-one running Windows 7 Home Premium 64 bit. The system I am currently using is running Windows XP Pro SP3.

Hi Sycho, for future reference, the full Firefox installers are available from the link below the green button labeled "Systems & Languages" which leads to:

http://www.mozilla.org/en-US/firefox/all/

I agree with everyone who says that is not very obvious and I don't know why Mozilla is using a stub installer now.

Many thanks to you, good sir, for the provided link. :)

I would hope that at some point the link to the stub get the axe as it's not worth the unnecessary aggravation.

@ Jaws13

I wanted to clear up some confusion on urls sent by crash reporter.

I've tested this many times myself over many years and it is not possible to view the url of the page Firefox crashed from the online crash report. The only way to see which url might have caused the crash is by going to the crash reports/pending folder and looking into the crash file BEFORE it's sent to Mozilla for processing. The file is named *random letters & numbers*.extra and contains a single url of the tab that was open at the time (or if you had more than 1 tab open, it uses the url of the tab that was focused at the time of the crash). I've never seen multiple page urls sent and I've checked this file regularly for about 6 years.

A easier way to see the crash url, is clicking on the "Details" button on the Crash Reporter dialog window. Scroll down inside the Details window until you see "URL:" and check the url yourself.

If you click submit on the Crash Reporter, almost always the crash is submitted instantly to the processing servers. Once this happens you can not view the .extra file anymore and lose your chance to see the crashing url later.

Once your crash report is finished processing and you go to view it, in all the available fields there is no url section. I've never seen one. And this has bothered me for times when I wanted to find out what the annoying website and the exact url was that caused my crash. Mozilla says they don't show the urls for privacy reasons so I guess it's for the best.

Also crash reports are deleted & sanitized of emails yearly, roughly. So the data isn't stored forever.

Jaws13,

Presumably you are still experiencing crashes. Perhaps after reading reading Noahs detailed reply above you may feel happy about submitting the standard crash reports.

If not and the reason is because of your need for privacy and not disclosing confidential URL s there is potentially a workaround. Run Firefox in a new clean additional profile. Browse around, without using confidential sites until it crashes. If you submit Firefox crash reports from that profile there will be no record of any confidential sites,and so no possibility of them being included in any report..

• Profile Manager - Create, remove or switch Firefox profiles

That will not prevent you from using the other Firefox profile for your confidential work. (if required there are methods of running simultaneous instances of Firefox each with a separate profile. )If the number or frequency of crashes drops off significantly then two of the possibilities are: crashes are being triggered by something in the crashy profile, or something on the crashy sites.

I also note there seems a possibility that Firefox could be at fault and that other things than Ghostery could trigger the crash. I suppose it would be especially useful if it happens that your crashes have a signature other than the ones we already have mentioned in this thread.

Jaws13,

For forum cross referencing purposes The crash report from your CrashID

• bp-b7d35575-f686-4161-bcf5-afb232130816

Give the same signature we were already aware of.

• Crash Signature: JSC::Yarr::YarrGenerator<int>::opCompileAlternative(JSC::Yarr::PatternAlternative*)
• Related bug Signature: Bug 814954 - crash in JSC::Yarr::YarrGenerator<int>::opCompileParenthesesSubpattern mainly with Ghostery

Sycho, Noah has already responded with the details, so I won't give much more information, but if you check the box to include the URL that you are on when Firefox crashes, that's pretty self-explanatory that the URL will get provided. Uncheck it if you are worried about it. Also, URLs are never accessible from the public website, and can only be accessed via-mini dumps that we only use when working 1 on 1 with a user, with that user's explicit permission.

The change to 23.0.1 seems to have fixed the problem... even before upgrading Ghostery to an even-more-recent version. I've had a work-related crisis and have barely been using the web over the weekend. That said, there's still a memory-leak problem in 23.0.1, but it's a performance issue and not causing crashes.

I have some comments concerning the "help" that's been offered in this thread that I'm hoping will be taken as constructive criticism:

(1) Read the whole bug report/help request before trotting out the damned boilerplate. In particular, don't demand data that isn't forthcoming as a condition of working through things... and don't suggest things that were already tried as "solutions."

(2) I'm quietly snorting in my coffee at the continued assertions that crash reports don't include URLs. They do so by default (a default that should be turned OFF), and it had been so long since I'd been forced to track down a bug that the version that I had been working with did not have that option. The less said about what someone who assiduously works through all of the data in a crash report can determine from that crash report, the better.

(3) When a complaint (or followup) specifically states that a possible workaround did not work, don't persist -- several hours/days later -- in suggesting that very workaround.

(4) If there's a maintenance release forthcoming soon, state that very early... not a dozen messages down, and in one's third "contribution."

(5) Stop blaming a third party's extension when multiple people concerned with a crash have already excluded it. In particular, don't blame a third party extension that is only providing functionality that should be built into the main program, if only as options. The more "pride of authorship" you have, the less likely you are to spot a problem with your own code -- even an unanticipated one.

(6) Whenever there's an Update Tuesday fix to Internet Exploder, and the Firefox complaint is coming from a Windows system, you should assume that a Firefox version and the Update are both attempting to address the same security flaw, or at minimum interfacing with the same subsystems. Given what the 23.0.1 maintenance update release notes say it addressed, I strongly suspect that's what is at issue in this particular complaint.

I'm not happy. I'm less unhappy than I am with the usual software tech support, because at least this time I had no trouble discerning what people were actually saying... but that's largely because the standard is so low.

Sorry you are not happy. Constructive criticism is good and although this is not the best place for such a discussion I will try to address some of your criticism.

(1) Read the whole bug report/help request before trotting out the damned boilerplate. In particular, don't demand data that isn't forthcoming as a condition of working through things... and don't suggest things that were already tried as "solutions." 

• I think this thread is pretty light on the "boilerplate" and that is used as an aid. Anyone in this thread (other that Tyler) is an unpaid volunteer and user like yourself. We could not run the forum without the boilerplate. Maybe you need to lower your expectations slightly given that this is free software and free support.
  • it is also intended that the thread have a single person asking a question, but inevitably things get complicated as others hijack your thread.
• it is often difficult to find reasons for crashes,and near on impossible without the CrashIDs

(2) I'm quietly snorting in my coffee at the continued assertions that crash reports don't include URLs. They do so by default (a default that should be turned OFF), and it had been so long since I'd been forced to track down a bug that the version that I had been working with did not have that option. The less said about what someone who assiduously works through all of the data in a crash report can determine from that crash report, the better. 

• If you feel strongly about that trawl through the developers fora to see if it has been discussed. If not start a discussion yourself and consider the possibility of filing a bug as an enhancement request. (I am not sure, but maybe there is a possibility that URLs are use to generate correlation reports).

 (4) If there's a maintenance release forthcoming soon, state that very early... not a dozen messages down, and in one's third "contribution."  

• Most recent releases have had at least one later fix
• Some of the decisions as to when or whether such a release will be made and what is to be included change fairly rapidly.
• Ideally anything needed should be able to wait at least until the next release, given that we are on a six week cycle.

(5) Stop blaming a third party's extension when multiple people concerned with a crash have already excluded it. In particular, don't blame a third party extension that is only providing functionality that should be built into the main program, if only as options. The more "pride of authorship" you have, the less likely you are to spot a problem with your own code -- even an unanticipated one. 

• The majority of crashes with that signature would have been from users with Ghostery. Many of the hundreds of readers of this thread probably solved their own problems by upgrading Ghostery.
  • you did not include details of your extensions when writing the question
  • yes it is acknowledged the problem could be triggered from Ghostery and be a flaw in Firefox code.
• Many crashes are related to third party software so it is a valid troubleshooting step to disable that.

 (6) Whenever there's an Update Tuesday fix to Internet Exploder, and the Firefox complaint is coming from a Windows system, you should assume that a Firefox version and the Update are both attempting to address the same security flaw, or at minimum interfacing with the same subsystems. Given what the 23.0.1 maintenance update release notes say it addressed, I strongly suspect that's what is at issue in this particular complaint. 

• Not sure I follow Given what the 23.0.1 maintenance update release notes say it addressed, I strongly suspect that's what is at issue in this particular complaint.
  • I was under the impression the main reason for the fix was the WebRTC Audio problem

 That said, there's still a memory-leak problem in 23.0.1, but it's a performance issue and not causing crashes. 

If you consider there is a memory leak you could consider starting a new thread, but unfortunately such issues are likely to require even more work and personal information from the reporter before they have the slightest chance of progressing towards a solution.

There is however an ongoing project to improve Firefox with regard to memory

• https://wiki.mozilla.org/Performance/MemShrink