Closed Bug 434403 Opened 16 years ago Closed 3 years ago

Startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] [@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ] (causes: Backdoor.Ulrbot.C Trojan, Spector Pro)

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: samuel.sidler+old, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: crash, regression, Whiteboard: [malware-crash])

Crash Data

Attachments

(8 files, 4 obsolete files)

The additional stack trace
9.57 KB, text/plain
Details
List of nsDocShell calls made on FF3 startup
45.34 KB, text/html
Details
stacktrace from crash
11.01 KB, text/plain
Details
Stack trace of crash
12.13 KB, text/plain
Details
Something to maybe try
1.80 KB, patch
Details | Diff | Splinter Review
Tryserver Build Stacktrace
9.21 KB, text/plain
Details
Stack trace from 9-23-08 build
8.58 KB, text/plain
Details
stack trace
7.20 KB, text/plain
Details 
We have a new startup crash on Windows in Firefox 3 RC1. This seems to occur after upgrading from beta 5 and may or may not affect upgrades from Firefox 2 (there's no conclusive data either way).

Stack from bp-0c89cdcc-241d-11dd-a994-001321b13766:

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsDocShell::SetupNewViewer 	mozilla/docshell/base/nsDocShell.cpp:6455
1 	xul.dll 	nsDocShell::Embed 	mozilla/docshell/base/nsDocShell.cpp:4870

Comment from the same crash report (the only comment so far):
  * I just updated from beta 5 to RC1. I CANNOT START IT UP! it just crashes! restarted computer, still the same.


Looking further, according to the query below, this occurred on upgrade to beta 5 as well (with the address of 0x0), but to a lesser extent. The uptime counts indicate it's a startup crash. It didn't occur in 3.0pre builds until 2008050206, afaict.
 http://crash-stats.mozilla.com/report/list?range_unit=months&query_search=signature&query_type=exact&product=Firefox&platform=windows&version=Firefox%3A3.0%2CFirefox%3A3.0b5%2CFirefox%3A3.0b5pre%2CFirefox%3A3.0pre&branch=1.9&signature=nsDocShell%3A%3ASetupNewViewer%28nsIContentViewer%2A%29&query=nsDocShell%3A%3ASetupNewViewer%28nsIContentViewer%2A%29&range_value=3

Currently, it's occurring in 3.0 RC 1 builds with an address of 0xffffffff80000000 and 0x0. Beta 5 only saw crashes in 0x0 and never at 0xffffffff80000000, which seems to indicate a recent regression that made this worse. The first crash at that address happened in the 2008050206 build.

Regression range from those builds: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-05-01+00&maxdate=2008-05-02+06&cvsroot=%2Fcvsroot

This points to bug 430624.

--

Finally, someone stopped by IRC (I've CCed him here) who is experiencing this crash. Running in safe mode, reinstalling, and trying a new profile did *not* fix this issue, however running in Windows Safe Mode did fix the issue. (Please correct me if I understood incorrectly). He also tried the build from 20080501 and had no problem but had a problem with 2008050206.
Flags: wanted1.9.0.x?
Flags: blocking1.9?
Renaming kbdamsys.dll allows fresh installs of build 05/02 and RC1 to load with no crash. Trying an install of B5 and then upgrade to RC1.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

Works with that file renamed. I did a clean install of B5 and then upgraded to RC1.

No crash.

Copied back my old profile and loaded with no crash.
Thanks for the help!
afaict nothing ensures aNewContentViewer is non null, this is almost certainly a crash because of that. the obvious patch should be applied.
It should certainly never be null in Firefox...
Assignee: nobody → chris
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Flags: blocking1.9-
Like I said, that should not be null...  Defending against null here will likely just crash at whatever callsite got confused.  Note, in particular, that the only callsite of SetupNewViewer ignores the return value.
Based on what Boris said, I don't think we want to just patch around this.
Attachment #322457 - Attachment is obsolete: true
I can't reproduce this, which makes debugging it very hard. Also the reported stack frames don't really make much sense, the crashing thread's entry point is in nsDocShell, not in WindProc or a thread runner or whatever, and there's only 2 frames on the call stack.

On one of the crash reports, nsDocShell::Embed() is called into by scrchpg.dll, which is from Kaspersky's anti virus scanner... But that's only in one case... There's not a lot to go on here...
I am running into this with FF 3.0. I am simply unable to install it on my Windows XP SP2 system.

I did a clean install. All I get is the Mozilla Crash Reporter.

Starting in FF Safe Mode does not work.

A couple of the Crash IDs (and their links) are:

A couple of the crash IDs (and their links) are: 

Crash ID: bp-ba34dbc2-3e58-11dd-937a-001cc45a2c28 
http://crash-stats.mozilla.com/report/index/ba34dbc2-3e58-11dd-937a-001cc45a2c28?date=2008-06-19-23 

Crash ID: bp-bfc2a045-3e58-11dd-8198-0013211cbf8a 
http://crash-stats.mozilla.com/report/index/bfc2a045-3e58-11dd-8198-0013211cbf8a?date=2008-06-19-23 

Joe
Attached file Stack trace of the problem (obsolete) — 
Stack trace I ran of the bug
Joseph, you successfully loaded symbols but your log doesn't show a stack trace. Do you know how to get a proper stack trace?
Attached file probably the trampoline (obsolete) — 
Oops. Forgot to run kp at the end (I'm following the instructions at http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg). I ran it twice. The results look different, so I am posting both results as stacktrace2.txt and stacktrace3.txt. Please let me know if this is better.

Many thanks.

Joe
Attachment #326071 - Attachment is obsolete: true
Here is stacktrace3.txt.

Again, many thanks.

Joe
BTW, I apologize for the screwups. Still learning! Interestingly, usually when I ran the debugger I would get an Access Violation. But looking at the two stack traces I just posted (id=326809 and id=326090), the first did not get an Access Violation whereas the second did.

Joe
Hmm.  That's certainly not a null-deref crash there...
Joe the stack in comment 13 looks like the wrong thread. The stack in comment 14 suggests Bug 344305 might be worth reading.
Attachment #326089 - Attachment description: Corrected stack traces → probably the trampoline
Attachment #326089 - Attachment is obsolete: true
At the suggestion of Chris, I disabled my McAfee and tried it again. Still getting the crash every time.
Flags: wanted1.9.1?
This attachment logs the different nsDocShell's being created and loaded and Stop()'d on FF startup. It's color coded so you can tell the different nsDocShell instances apart.

I think the problem is somewhere in session restore. The problem is probably another instance of bug 344305, where an about:blank was loading and interrupted by something else being loaded.

In this attachment, I'm interested in the pink nsDocShell, id=4. This is the Getting Started page being restored from session history. The nsDocShell begins loading about:blank, then session history stops the load and starts it on the Getting Started page.

Could we be having some re-entrancy or interleaving in session restore/nsDocShell here that's causing the crash? I don't see any calls to nsDocShell::Destroy() near here, they're all near the bottom of the log.

BZ, do you have any insights about this?

I've also had a look over the patch for 430624 but I can't imagine how any of the changes in it could actually be hit on app startup, as all the changes are guarded by null checks on nsDocShell::mEditorData and/or on an aSHEntry history entry method parameter, which is usually taken from nsDocShell::mOSHE, and mOSHE is null until page load is complete. Clearly something must be different though. :/
Adding myk to CC. Myk, you fixed bug 344305, which is pretty much the same as this one, do you have any ideas on this one?
Attached file stacktrace from crash — 
I'm experiencing this exact same crash on Windows XP SP2 with FF 3.0 GA.  I've attached a stacktrace in case it helps, but it's very similar to what Joe has already provided.  Let me know if there is more debugging I can do.  I ran through the debugger twice and the results were identical (except for some address locations, of course) so I'm only submitting one stacktrace.

Steps to reproduce through the UI:
1. Launch FF
2. Click on the "Options" menu
(FF crashes after 15-30 seconds of other normal operations as well, but the above steps are how I reproduced in order to take the stack trace.)
Note that my fix for bug 344305 didn't actually fix the bug that bz identified in bug 344305, comment 18.  It just worked around it, per bug 344305, comment 19.  So it's quite possible that something else is now triggering the same bug.

I don't think we're hitting that situation, since in this case the Embed() is from the nsDocShell::EnsureContentViewer call (in the stack in comment 21, at least), which means there is no old viewer to stop as in bug 344305, comment 18.
Here's my Crash Report for what I believe is the same bug.

Any sort of normal use causes the crash. Opening new tabs or dialog boxes does it the quickest.

I've done the following:
Removed all Anti-Virus & Firewall software (AVG 8)
Removed Google toolbars
Uninstalled all network monitoring/filtering software
Disabled ALL add-ons, extensions, and plugins

It still crashes in firefox safe mode. Haven't tried it in Windows safe mode. Who knows.

http://crash-stats.mozilla.com/report/index/3853055c-454e-11dd-8959-0013211cbf8a
Since I am unsure of the etiquette of the process, should we nominate this as blocking for 1.9.0.1 and/or 1.9.1? Is it too late in any event for 1.9.0.1?
It's probably too late for 1.9.0.1, unfortunately.
Dan, do you crash when you start up with a new profile?
http://kb.mozillazine.org/Profile_Manager
Flags: blocking1.9.1?
Yes, even with a blank profile.

Sorry it took a while for me to reply. I just wanted to make sure that it still was crashing with 0 plug-ins and add-ins. Some days it's good, some days it can't stay open for more than a few minutes.

Usually after a reboot of Windows it will stay open for longer periods of time. I usually don't reboot more than once a week though.
So it sounds like:

1) This happens for clean installs (not installs on top of an older release or beta or whatnot).
2) This happens with clean profiles.

Is that correct?

Do the people seeing this crash have any plug-ins (not extensions)?  Does disabling the Java plug-in (if any) make the crash disappear?

I've been auditing the code involved here and haven't found a way that pointer can end up dangling, but I'm still looking.
The Java plug-in is disabled. Clean install, clean profile.

Is there any rhyme or reason as to what crash reports crash-stats analyzes? I've only gotten 1 to even complete analyzing.
(In reply to comment #28)
> So it sounds like:
> 
> 1) This happens for clean installs (not installs on top of an older release or
> beta or whatnot).

This was originally first discovered when someone upgraded from beta 5 to RC1. See comment #1. IIRC FF3 beta N has "beta N" in the default install directory path, but RC candidates didn't, so these should be installed in separate directories.

> I've been auditing the code involved here and haven't found a way that pointer
> can end up dangling, but I'm still looking.

My guess is that it's in session store, but I can't see how.

I see Brett Shomaker's stack trace is je_malloc'ing 0 bytes, which is interesting.

It's also using the same nsCOMPtr_helper* value (0x606cbd4e) as an nsID* deeper in the stack. Would that be the result of a compiler optimization?
My issues were resolved 100% with comment #1, have the other people having this issue checked for that file, or is this more a general thing at this point?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008070213 Minefield/3.1a1pre ID:2008070213
Boris,

Clean profile, clean install. I followed the Mozilla instructions for a clean install. My specific steps were:

1. I uninstalled FF from the Control Panel 
2. I went to C:/Program Files/Mozilla and deleted the entire Mozilla 
folder 
3. I went to c:/Documents and Settings/MYNAME/Application Data/Mozilla 
and deleted the entire Mozilla folder 
4. I went to c:/Documents and Settings/MYNAME/Local Settings/ 
Application Data/Mozilla and deleted the entire Mozilla folder 
5. I went to c:/Windows/Prefetch/ and deleted everything related to 
Mozilla/FF.
6. I went to the Recycle Bin and emptied the Recycle Bin. 
7. I ran a registry cleaner. 
8. I then rebooted my system.
9. Went to the FF website and downloaded the installer.

No plug-ins, no extensions. Still get this error. FF simply won't start.
Beyond the stacktrace with WinDbg, is there a more sophisticated and thorough debugging process that I could do to help? Even though I am still learning programming, I work for a software company so could always get some help (unfortunately, this is happening on my home machine, not my work machine). I'd be happy to download the source and run more sophisticated debugging tools if someone could walk me through the process.
This may be a few different problems. Mine *used* to not start, now it starts all of the time, but still crashes occasionally. It's very random. I'd consider it a memory issue, or some other problem, but it's the only app on my system I have issues with.

And in response to Joseph Becher: I don't have the file kbdamsys.dll on my system.
Joseph Jacob, you should be able to compile Firefox yourself following the instructions at <http://developer.mozilla.org/en/docs/Build_Documentation>.  If you compile it and if the resulting build shows the problem, you could indeed get more information out than just a windbg stack trace.  I'm just worried about the "if the resulting build shows the problem" part for now, so no point discussing how to get the information until we know that happens.

Does anyone know what kbdamsys.dll actually is?  What program does it come with (sounds like it's not a Windows default at least)?  I realize not everyone here has it; just trying to gather information still.
No clue. I sent the file to someone, maybe Cww, to decomplile, but never heard back on that and can't remember who it was. Maybe SS remembers?
I should also note that I do not have the kbdamsys.dll file on my system either.
Boris, I will compile Firefox tonight. In order to have apples-to-apples comparison, I will use the source from FF 3.0 and not the most recent nightly build.

I'll let you know the result this weekend (assuming I am successful....)
So as far as I can tell, assuming we're creating the content viewer via nsLayoutDLF (which in Firefox should always be the case, as long as no one is overriding about:blank creation via some crazy extension) the viewer should still be alive when we get into Embed()...

Joseph, I really hope you'll be able to reproduce this in a self-compiled debug build.  :(
Quick question - which is the correct source code line for the actual 3.0 release at this URL?

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
The FIREFOX_3_0_RELEASE CVS tag is probably what you want.
Chris, I just saw comment 19.  Does that log correspond to a case when you reproduced the bug?
No, sorry, I've never been able to reproduce the crash. That's just me trying to figure out what happens during startup.
Are any of you running the application RescueTime?
(In reply to comment #44)
> Are any of you running the application RescueTime?

I am not.  I run another time tracking tool called TimePanic, but that tool doesn't have a browser plug-in, so I don't think it's relevant.
After months of regular crashing, my problems disappeared the second I uninstalled RescueTime. I haven't had a crash in 3 days, where it usually crashed every 15 minutes. It's an app that hooks into your browser to monitor the urls being visited.

http://getsatisfaction.com/rescuetime/topics/rescuetime_crashes_firefox_3
"We have identified a specific call to Firefox 3 that will periodically cause crashes (AccessibleObjectFromWindow). Another user has a set of JavaScript test files that seem to trigger something in Firefox that will cause any calls to AccessibleObjectFromWindow to crash Firefox 3."
Guys, could you look into this issue with RescueTime?
(In reply to comment #47)
> Guys, could you look into this issue with RescueTime?

Looks like that's a different crash, with a different callstack.

FWIW I installed RescueTime yesterday, and I've not had FF3 crash yet.
AccessibleObjectFromWindow usually means that Accessibility should be fired up first by some WM_GETOBJECT message. Screen readers send that if they can't identify a certain window some other way, to see if MSAA (Microsoft Active Accessibility) is enabled and gives some useful reply.

So my guess is that someone is trying to use our APIs without firing them up properly first.b
I have been afflicted with this bug as well. FF was working fine for about two weeks. That was a clean install of FF3. The start of the crashing may coincide with the update to 3.0.1. Like the others I get the crash reporter on startup. The FF window will show for a split second before crashing. There are two tabs visible. I've tried safemode, same result. I've done clean profiles and clean installs, same result. Even crashed while using the -profilemanager switch.

Here are some of my crash reports:
http://crash-stats.mozilla.com/report/index/2b3953dc-5726-11dd-bc2e-001cc4e2bf68?date=2008-07-21-13
http://crash-stats.mozilla.com/report/index/a1c902b8-58b1-11dd-8f7b-001321b13766?date=2008-07-23-12
http://crash-stats.mozilla.com/report/index/a089ba3d-574c-11dd-88e1-0013211cbf8a?date=2008-07-21-17

I do not have kbdamsys.dll or RescueTime installed on my computer. This computer is used in a cororate environment and has McAfee Virus Scan Enterprise and ePolicy Orchestrator Agent installed on it. I disabled the McAfee "On-Access Scan" and FF still crashed the same way.

I have attempted to run a stack trace and will attach the result of that.
Attached file Stack trace of crash — 

    
    

    
  
Paul, is there anything on the stack past the OpenWindow call?

    
    

    
  
(In reply to comment #52)
> Paul, is there anything on the stack past the OpenWindow call?

No. I just tried it again. That is all that spits out when you do the kp command. FWIW I don't really know what I am doing with WinDbg. Just following the instructions in the page linked to in Comment #13. I should also mention that this is on XP Pro SP2.

    
    

    
  
Hmm.  That's really really weird....  _something_ should be making the OpenWindow call...
Flags: blocking1.9.0.3?

    
    

    
  
Joseph, I was looking at the code again, and I might have an idea of what's going on.  When you crash, can you take a look at whether the nsDocShell object has actually been destroyed (e.g its mIsBeingDestroyed member is > 0)?

Alternately, would you be able to try out the patch I'll post in a minute?

    
    

    
  
Boris, I'd be happy to try out a patch. First, can you let me know how to determine whether mIsBeingDestroyed member is > 0? I'm going to also try this Labor Day weekend to build FF from source to see if that works - I ran into some troubles last time, but I think I know what I was doing wrong.

    
    

    
  
I don't actually know WinDbg well enough to tell you what the right commands to run are....  :(  I'll see whether I can dig those up.

    
    

    
  
(In reply to comment #58)
> I don't actually know WinDbg well enough to tell you what the right commands to
> run are....  :(  I'll see whether I can dig those up.

Timeless, could you help out?

    
    

    
  
you have a couple of choices. one is view>locals, another is view>watches and the last is view>command

in command you can try something like:

dt this nsDocShell mIsBeingDestroyed

for information try: .hh dt
(in case i happen to have the syntax wrong)

    
    

    
  
(In reply to comment #57)
> Boris, I'd be happy to try out a patch. First, can you let me know how to
> determine whether mIsBeingDestroyed member is > 0? I'm going to also try this
> Labor Day weekend to build FF from source to see if that works - I ran into
> some troubles last time, but I think I know what I was doing wrong.

If building FF from source is still blocking you, there's another option: we can build with Boris's patch on our TryServer and send you the build to run on your machine.  Building from source on your own machine is a worthwhile investment in future bug tracking, so that's definitely encouraged, but a little extra work on our side might save you a lot of effort in the short term.

    
    

    
  
Ben, I'd be happy to run a build with Boris's patch. Just let me know how to get it.

    
    

    
  
Joseph, I've started the try server to create a build with Boris patch. Just download the file you need and start the application afterwards.

The builds will be available soon:
https://build.mozilla.org/tryserver-builds/2008-09-14_15:10-mozilla@hskupin.info-bug434403/

    
    

    
  
Hi Henrik and Boris,

I downloaded the .exe file from the location at build.mozilla.org, and installed the application. When I went to run Minefield, I got a dialog box after about 5 seconds with the title "firefox.exe", and the text stated "firefox.exe has encountered a problem and needs to close. We are sorry for the inconvenience." This happens every time I try to start it up.

    
    

    
  
I should also note that after starting Minefield failed a few times, I tried starting it in Safe Mode, but I got the same crash message.

    
    

    
  
Joseph, I hope you are using a fresh profile? One thing I forgot to mention is that the tryserver build is based on the latest development build and could cause problems like dataloss in your profile. If you haven't done this yet, please do so. Also for further tests.

Please see:
http://support.mozilla.com/en-Us/kb/profiles

Does this crash also happens with a fresh profile? Can you provide the stack trace again so we can see if it differs? Thanks.

    
    

    
  
Henrik, it is a fresh profile. Each time I try an installation of Firefox, I take the following steps with respect to my previous installation of Firefox (I'm using Windows XP with Service Pack 3):

1. I uninstall FF from the Control Panel 
2. I go to C:/Program Files/Mozilla and delete the entire Mozilla 
folder (if there is still one)
3. I go to c:/Documents and Settings/MYNAME/Application Data/Mozilla 
and delete the entire Mozilla folder 
4. I go to c:/Documents and Settings/MYNAME/Local Settings/ 
Application Data/Mozilla and delete the entire Mozilla folder 
5. I go to c:/Windows/Prefetch/ and delete everything related to 
Mozilla/FF

I took these steps before installing the tryserver build. I'll run a stacktrace and post it.

    
    

    
  


  
Here is the stacktrace from the Tryserver build.

    
    

    
  
Hmm...  Those might not be the right symbols for that build; the stack certainly doesn't make sense.  It's interesting that this is causing a crash, given that all I'm doing is holding a strong reference to a known-good pointer.

Joseph, would you be able to try a build from ftp://ftp.mozilla.org/pub/firefox/nightly/2008-09-14-03-mozilla-central/ and see whether that also crashes reliable on startup?

    
    

    
  
Boris, you're probably right about the symbols. I'll try the build from the location you specified when I get home tonight.

    
    

    
  
Boris, when I installed the nightly, the Mozilla Crash Reporter came up when I tried to launch the application. The details were:

BuildID: 20080914034157
CrashTime: 1222220291
InstallTime: 1222220285
ProductName: Firefox
StartupTime: 1222220288
URL: 
UserID: db478a76-aada-48b0-a0ba-45ad7d59d836
Vendor: Mozilla
Version: 3.1b1pre

This report also contains technical information about the state of the application when it crashed.

I then did a complete uninstall and downloaded the most recent nightly build at 
ftp://ftp.mozilla.org/pub/firefox/nightly/2008-09-23-11-mozilla-central. After installing this and trying to run the application, I again got the Mozilla Crash Reporter, with the following details:

BuildID: 20080923111052
CrashTime: 1222220937
InstallTime: 1222220932
ProductName: Firefox
StartupTime: 1222220935
URL: 
UserID: b4d106e4-aea6-4b6d-a2b4-f375009f3b11
Vendor: Mozilla
Version: 3.1b1pre

This report also contains technical information about the state of the application when it crashed.

I'll run WinDbg on this executable and get a stacktrace.

    
    

    
  


  
Here is the stacktrace from the 9-23-08 build.

    
    

    
  
(In reply to comment #71)
> UserID: db478a76-aada-48b0-a0ba-45ad7d59d836

Joseph, thanks for digging again into the problem. Could you please offer the crash id? You can get it by opening "about:crashes". Like the UserID it is a GUID which you can copy&paste here.

    
    

    
  
Boris, it looks like that current nightly builds still crash with that stack.

    
    

    
  
Hrm.  All three show the same crash; a crash in nsDocShell::SetupNewViewer at the first place we make a call on newMUDV.  Now this is not the first place inside SetupNewViewer that we make a call on aNewViewer: we've already QId it (to get newMUDV), and assigned it to mContentViewer (which addrefs it).  That's exactly what the stack in comment 14 showed...

So...  Chances that aNewViewer is a bogus pointer are low: we've already made several virtual calls on it.  We're holding a strong ref to newMUDV, but we didn't addref it ourselves: QI did that.

Is it possible that somehow QI returned a bogus pointer, I wonder?

Joseph, do you think that you can take a look, in a crashing build that you have symbols for, and tell me what the values of aNewViewer, newMUDV.mRawPtr and mContentViewer.mRawPtr are?

    
    

    
  
We'd love a branch patch but will wait until it's done on trunk.
Flags: blocking1.9.0.4?

    
    

    
  
hello.i want to use the beta version at work.but it doesn't work.
i can reproduce the bug.how can i help?

    
    

    
  
(In reply to comment #78)
> hello.i want to use the beta version at work.but it doesn't work.
> i can reproduce the bug.how can i help?

Tasoss, what did you do that Firefox crashed? Does the crash happen on startup? Do you have a crash report (enter the url 'about:crashes' and c&p the appropriate entry here)? Did you do the test with a fresh profile and no add-ons installed?

Rank #9 in top crasher list of Firefox 3.0.3. Here a given comment (sadly no-one else enters useful information here :/):

* Installed the latest firefox, started it up, said no to import from explorer and then it crashes

    
    

    
  
Hello Henrik.
It crahes on nightly builds at startup.
All the computers at work have this problem.
Let's start with:
http://crash-stats.mozilla.com/report/index/61c71b51-9e73-11dd-b400-0013211cbf8a?p=1
Btw a question.I have submitted a lot of crash reports related to this bug.Does anyone watches them?
Please check the crash report and let me know.I would like to help so you can solve this problem.Can Windbg help you more?

    
    

    
  
That looks like exactly this crash, yes.

If you can get the info I mention in comment 76, that would be lovely.

Past that, can anyone try to figure out what it takes to reproduce this?  Particular install location?  Particular Windows version?  Something else?  If I could just reproduce this ought to be reasonable to fix... :(

    
    

    
  
Joseph: Do you have a virus scanner installed? I'm just wondering what the file C:\WINDOWS\system32\favalin.dll is about. Could you maybe scan the file under http://virusscan.jotti.org/ if it's something suspicious? If you want, you can also send that file to my mail address and I'll do it.

    
    

    
  
(In reply to comment #80)
> Hello Henrik.
> It crahes on nightly builds at startup.
> All the computers at work have this problem.
> Let's start with:
> http://crash-stats.mozilla.com/report/index/61c71b51-9e73-11dd-b400-0013211cbf8a?p=1

The modules list of your crash report contains "hexosxml.dll". I get zero hits on Google for that DLL name. Can you find that file, and submit it to an online virus scanner?

    
    

    
  
We had someone on #firefox a while ago with every system in the office having Firefox crash at startup, with crash reports like:

http://crash-stats.mozilla.com/report/index/db098940-7345-11dd-8eaf-001a4bd43ed6?date=2008-08-26-08

and

http://crash-stats.mozilla.com/report/index/a3cbb866-9455-11dd-9d1c-001cc45a2c28?p=1

which look rather similar to this crash (it's also @ nsDocShell::SetupNewViewer(nsIContentViewer*) although the rest of the stack is missing for some reason).

We noticed that the Firefox processes crashing like that all had two dlls loaded with zero or almost zero google hits on their name and no version information. Throwing those dlls at http://virusscan.jotti.org/ confirmed one of them was malware ("Backdoor.Ulrbot.C"). I'm assuming getting rid of the dlls helped, but the user did not explicitly report back to #firefox (just vanished after we figured out the malware was there). Also worth noting that the office did have a virus scanner and firewall in place, but this apparently slipped through (most of the scanners jotti.org runs did not catch it either).

So it might be interesting to see what virusscan.jotti.org makes of the dlls mentioned in the comments above.

    
    

    
  
Hello again.
Results from scanning
Ikarus 	Found Backdoor.Ulrbot.C 
But the fact is that a colleague of mine,doesn't have this file and still it crashes.
Have a look at my colleague's crash report
Is there any way to keep the dump file?
I mean,when i submit the crash,i can't save the dump file because it's deleted.
I think i need the dump file in order to do what Boris said,about comment #76.

    
    

    
  
(In reply to comment #85)
> Hello again.
> Results from scanning
> Ikarus     Found Backdoor.Ulrbot.C 
> But the fact is that a colleague of mine,doesn't have this file and still it
> crashes.
> Have a look at my colleague's crash report
http://crash-stats.mozilla.com/report/index/aa0d7f85-9f3e-11dd-8548-001a4bd43e5c?p=1
> Is there any way to keep the dump file?
> I mean,when i submit the crash,i can't save the dump file because it's deleted.(Forget it i just found a solution)
> I think i need the dump file in order to do what Boris said,about comment #76.

    
    

    
  
i think i have done it
aNewViewer=0x01cc9110 class nsIContentViewer *
newMUDV.mRawPtr=0x00000000 class nsISupports *
mContentViewer.mRawPtr=<Memory access error>

    
    

    
  
(In reply to comment #85)
> But the fact is that a colleague of mine,doesn't have this file and still it
> crashes.

The file name is random, which is why google doesn't return anything when searching for it. It's almost certain your colleague won't have a file with the same name, but the real question is if he's got the same virus.

Can your colleague check his delumie.dll file.

    
    

    
  
i have installed antivir and ad-aware.
They haven't found anything.I'm in production environment so i believe that it's impossible to have a virus.
Maybe it is from some spy software that may be installed?Because we already have a service running,spying us.
At colleague's pc delumie.dll is found.
Found Backdoor.Ulrbot.C 
Results are the same with mine.But using windiff the files are completely different but the date is the same.

    
    

    
  
(In reply to comment #89)
> i have installed antivir and ad-aware.
> They haven't found anything

Tasoss, what anti-virus software are you running? Does it have up to date virus definitions? It sounds like a virus could be interferring with FF - it would explain why we don't have the bug, if we don't have the virus.

> I'm in production environment so i believe that
> it's impossible to have a virus.

I wouldn't count on that! ;)

> Maybe it is from some spy software that may be installed?Because we already
> have a service running,spying us.

I think that sounds likely. Can you check that your virus software is up to date with the latest virus definitions? Maybe try another one as well, like AVG (it's free).
Summary: startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] → startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] (caused by Backdoor.Ulrbot.C Trojan)

    
    

    
  
(In reply to comment #89)
> i have installed antivir and ad-aware.
> They haven't found anything.I'm in production environment so i believe that
> it's impossible to have a virus.

Anti-virus software is not flawless. No single av product picks up each and every virus and trojan, unfortunately. Perhaps someone who ran the file through jotti's service can report back which scanner(s) actually found something?

Note that the reporter I mentioned in comment #84 was in an office, with a decent virus scanner running, so he also considered a virus unlikely. It was still there and affecting most systems in the office. He suspected it actually came in through a mailing list the entire office was on (and reading using the same client). And because the software on those systems was similar (and the virus scanner identical) if it goes undetected on one system it probably goes undetected on all of them. A mostly homogenous environment like this can actually make it *easier* for the malware to move around.

> Maybe it is from some spy software that may be installed? Because we already
> have a service running, spying us.

This is possible, but please still check for unknown dlls in your crash report(s) and feed them to a scanner like jotti (or to a particular local scanner once we've confirmed which one(s) currently pick up this malware). For the report from comment #80 that would be hexosxml.dll. If you provide other crash reports we can quickly locate suspicious dlls now that we know to look for them.

> At colleague's pc delumie.dll is found.
> Found Backdoor.Ulrbot.C 
> Results are the same with mine.But using windiff the files are completely
> different but the date is the same.

The files having a different name is expected here. It is also quite possible for the files to differ while actually being the same malware (malware tends to do things like this to make it harder for av software to detect). There are ways to encrypt and/or compress the file on disk making the variations almost completely different there but turn into the same program in memory when actually executed. Virus scanners try to reverse such trickery without actually executing the program, but again not all scanners can undo all those tricks.

Could one or more people with the problematic dll report which scanner(s) run by jotti actually detect it (so that we also know that the other ones do not, and people running the same scanner locally are not safe)?

    
    

    
  
Interesting.  So for people who want some info on Backdoor.Urlbot(.C) here's a page: http://www.antispyware.com/glossary_details.php?ID=134219

It sounds like this particular virus might be trying to infiltrate Firefox in addition to whatever else it does, and if it was designed to do that with Firefox 2 and then tries to do the same thing with Firefox 3 I can definitely see all sorts of weirdness going on (due to the changed vtables, etc, etc).

> aNewViewer=0x01cc9110 class nsIContentViewer *
> newMUDV.mRawPtr=0x00000000 class nsISupports *
> mContentViewer.mRawPtr=<Memory access error>

The second indicates something pretty broken happened when QI was called (something that can't happen with the unmodified Gecko code), and the third indicates that in general the |this| object is lala-land or something...

    
    

    
  
So I guess the first question is this:  Does removing those Backdoor.Urlbot.C files fix the problem?

    
    

    
  
Hello.I'm using antivir(http://www.avira.com/en/pages/index.php)
Of course it's updated.
Antivir doesn't identify it as a virus.
as i have already mentioned only ikarus scanner found it as Backdoor.Ulrbot.C 
Ikarus     Found Backdoor.Ulrbot.C
I also tried delumie.dll(from my colleague's pc which was detected again only
by ikarus as Found Backdoor.Ulrbot.C
We are using
http://www.gfi.com/endpointsecurity/(running as a service)
if this helps...

ps:The problem is that read access is not allowed for this file.
So i have to ask an admin to scan it in safe mode...
and let you know.

    
    

    
  
Boris the specified scanner didn't detect anything.
I have to wait for an admin to scan in safe mode.

    
    

    
  
Scan what?  What I'm asking is whether any of the folks who were seeing this crash _and_ have the Backdoor.Ulrbot.C file see the crash go away once the virus is removed.

    
    

    
  
Yes.I do have it and it cannot be detected.And yes it crashes.

    
    

    
  
I'm not asking you whether it can be detected.  I know you have it.  If you now DELETE it, what happens?

    
    

    
  
Boris i was waiting for an admin so  i can login in safe mode.
We deleted the file and IT'S WORKING :-)
I'm so happy :)
thank you very much!

    
    

    
  
This is a fairly common support issue.  In light of having users help themselves, do we at least know in which folder people may be able to find this file or any way that they can identify it without tracking down someone from Mozilla to vet all the dll files in their crash report stack?

Does the removal tool linked in comment 92 work?

    
    

    
  
(In reply to comment #100)
> any way that they can identify it without tracking down someone from
> Mozilla to vet all the dll files in their crash report stack?

It appears easy so far: open the crash report, go to 'modules' section and see which module(s) don't have a file version (second column blank).

In the above crash reports there's only been one module with no version, but technically there can be more. Paste their name(s) into google and if there's no results, that's the virus.

> Does the removal tool linked in comment 92 work?

That would be ideal...

    
    

    
  
> Does the removal tool linked in comment 92 work?
as i have already posted,no it doesn't.
the only thing that worked is using
http://virusscan.jotti.org/
Ikarus antivirus recognised it as Backdoor.Ulrbot.C.

after informing the admin that the specific dll caused such a problem i removed it.but after one day he told me to put it back.in my case i'm 100% sure that the sniffing service that the computers run in order to snoop the employees is related with this dll.
anyway,the fact is that it's not a bug of mozilla.

    
    

    
  
You had a .dll associated with known spyware, that was crashing a program you use regularly, and your admin made you put it _back_?

    
    

    
  
So we can't block on this because it's caused by spyware. We'd probably take a sensible workaround though, it would be nice to not crash. :-/
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1?
Flags: blocking1.9.1-

    
    

    
  
#104 because the service that snoopes the employees needs it.
#105 that would be great(i wish i could use nightly build) but i think it has nothing to do with the development of mozilla.i mean if developers have to fix everything that a spyware/virus etc causes crashes,that would be impossible.am i wrong?
the good news is that now we know the reason.

    
    

    
  
Tasoss (or anyone else who is crashing), can you please download and try this build of Firefox:

https://build.mozilla.org/tryserver-builds/2008-10-29_17:13-cpearce@mozilla.com-cpearce/cpearce@mozilla.com-cpearce-firefox-try-win32.zip

I added some checks, hopefully it will work...

    
    

    
  
unfortunetaly it crashes.i tried safe-mode(crashes).normal-mode trying to create a new profile(it crashes here too).normal-mode choosing a profile(crashes).
of course it doesn't help you but just mentioning.
Unhandled exception at 0x103f1df0 in firefox.exe: 0xC0000005: Access violation reading location 0x00000000.

    
    

    
  
Thanks Tasoss. That build had extra error checking etc, so I doubt there's anything we can do on our end to fix it...

    
    

    
  
interesting that this crash jumped to #6 in the rankings after the 1st day of the 3.0.4 release.

    
    

    
  
I've taken a look at a couple of these reports and each one lists some bogous DLL files which have random names and cannot be found by searching on Google. Looks like that Firefox 3.0.x can be used to detect this trojan.

    
    

    
  
Henrik, interesting findings.   We have been thinking about interesting ways to analyze the module list in bug 423968.  

I've added your comment 111 to that bug.

    
    

    
  
(In reply to comment #110)
> interesting that this crash jumped to #6 in the rankings after the 1st day of
> the 3.0.4 release.

Probably people download 3.0.4, find that it doesn't work either, and then go back to their usual browser.

    
    

    
  
This is all very interesting. Firefox 3.0.x does not work on my home computer but it works on my work computer. On my home computer I have installed Spector Pro to monitor my kids' activities. Firefox 2.x works on my home computer, but Firefox 3.0.x never has.

I wonder if it would be useful to try to see which bug fixes caused the incompatability. Would it be useful for me to try to load various alphas/betas along the road to 3.0.0 in order to try to find the bug fix that broke it?

    
    

    
  
Depending on what "Spector Pro" is doing, something as simple as an interface change could cause the problem...  In fact, I would wager money that that's what happened.

    
    

    
  
(In reply to comment #114)
> On my home computer I have installed Spector
> Pro to monitor my kids' activities

Out of curiosity, did you check if this Spector Pro is the reason? It would be interesting if this backdoor - which behaves as a virus and is caught by anti-virus software - was part of, or employed by, otherwise useful (and paid) application.

> I wonder if it would be useful to try to see which bug fixes caused the
> incompatability. Would it be useful for me to try to load various alphas/betas
> along the road to 3.0.0 in order to try to find the bug fix that broke it?

Nah it's pointless. Like Boris says, the backdoor attaches itself to firefox and makes some assumptions about how firefox works *internally*. Any internal change - and they have been all over the board between ff2 and ff3 - will make this assumption fail and the application will crash and burn.

    
    

    
  
Not sure if this will help you guys, but I had this happen on a third computer on my network. The first two it happened to a while ago. Then, yesterday after upgrading 1 to 3.0.4 it happened again. There seems to be no way to fix it. I have tried everything several times. The only way I can run FF is if I do a "run as" and use the local admin account. Seeing the comments about Spector got me thinking. I DO use Spector here, and I have an exception setup in it so that it doesn't record the local admin. Maybe I will add the other user as an exception and try again. I have downgraded the 3 computers to version 2 and all has been well, but as you know that is not a permanent solution nor is is the best solution....

Let me know if I can be of any assistance.

Jeff

    
    

    
  
OK, so I did some looking into Spector Pro.

1)  This product was in fact developed based on a virus, which is why virus scanners are catching it.  See http://www.pcmag.com/article2/0,2817,244681,00.asp

2)  This product is definitely known to cause crashes with Firefox 3.  It seems like they deny all, but the most recent version is compatible.  See http://forums.mozillazine.org/viewtopic.php?f=38&t=891225&start=0&st=0&sk=t&sd=a

    
    

    
  
FYI I have the most recent version. I just went through an upgrade 2 weeks ago with their support team.

    
    

    
  
Sounds like you should contact them and complain about them crashing Firefox, honestly.  They're doing completely unsupported things of some sort, messing with our internal data structures, and it's not working right.

    
    

    
  
Now that you mention Spector Pro, I was using it too when I was having the crash issues, is exetomon.dll by chance part of Spector Pro?

    
    

    
  
The file names on the client are generated at random to avoid detection so its hard too say. I don't know the full list of possible file names or if one even exists.

    
    

    
  
(In reply to comment #113)
> (In reply to comment #110)
> > interesting that this crash jumped to #6 in the rankings after the 1st day of
> > the 3.0.4 release.
> Probably people download 3.0.4, find that it doesn't work either, and then go
> back to their usual browser.

It may suggest that the problem is more widespread than the general ranking (outside of a new/updated release) of this problem would suggest. It's the kind of issue where after you try installing and it doesn't work, you simply go back to using FF 2.x or to IE, rather than trying it again and again.

    
    

    
  
What is the status of this bug?  My girlfriend finally told me that she crashes at every single startup when using the desktop icon.  If she clicks a link, firefox 3.0.4 opens without issue.  She sent me one of the crash ids http://crash-stats.mozilla.com/report/index/9fcd268b-1e20-4f9a-b944-330c12081201?p=1

    
    

    
  
your girlfriend has a trojan/virus in a file called "mp4irusb.dll" find a good cleaner

    
    

    
  
(In reply to comment #125)
> your girlfriend has a trojan/virus in a file called "mp4irusb.dll" find a good
> cleaner

Thanks!! Following the steps at http://support.mozilla.com/en-US/kb/Firefox+crashes+when+you+open+it#Backdoor_Ulrbot_C fixed the problem.  Apparently sine she updated to Firefox 3.0 she hasn't been able to start it with the desktop icon since then but was able to click on links from outlook and Firefox would launch.  Weird that it worked that way though.

    
    

    
  
Ok, I have confirmed that it is definitely Spector that is causing this issue. I reinstalled FF3 on one of the problem computers and it immediately started crashing again just like before. Then I went to the Spector control panel and set up an exception for FF (what this does is stops it from recording FF activity). As soon as I did this, FF started working again.

I have been in touch with Spector support and they are supposed to send me some possible resolutions to the issue. I will post and let everyone know how it goes.

    
  
Summary: startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] (caused by Backdoor.Ulrbot.C Trojan) → startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] (causes: Backdoor.Ulrbot.C Trojan, Spector Pro)

    
    

    
  

      
      
      
      

        Attached file
          
        wrong process (obsolete)
        — 
      

    


  
stack trace from Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081215 Shiretoko/3.1b3pre

    
    

    
  
Comment on attachment 353197 [details]
wrong process

you didn't check debug child processes as described in http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

        Attachment #353197 -
        Attachment description: stack trace → wrong process

        Attachment #353197 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached file
          
        stack trace
        — 
      

    


  
stack trace from Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre)
Gecko/20081215 Shiretoko/3.1b3pre
"Debug child processes also" check box is checked.

    
    

    
  
For all with the Spector issue, I have been given a newer build from 
Spectorsoft which seems to have solved the problem.

    
    

    
  
Thanks, Followed the steps linked to in comment <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=434403#c126">126</a> and it fixed the crash issue.

    
    

    
  
Hi there. I'm not entirely sure this is the right place to be putting this information but I figured, if anything, it couldn't hurt. 

Unfortunately, past what I say, I doubt I can be more help since it works now. 

I did file the following reports:
http://crash-stats.mozilla.com/report/index/0b6fbe79-6cf9-4b3f-8467-718252090318?p=1

http://crash-stats.mozilla.com/report/index/0cc434b1-bcf7-42ff-ba5d-9ae8e2090318?p=1

http://crash-stats.mozilla.com/report/index/7dafbded-b0e3-447c-bfed-f6e372090318?p=1

And about 15 more (Sorry I tried everything). 
The process I went about fixing it does not make sense (I'm a developer and I don't believe this was the cause of the fix). 

1) Replaced the Flash DLL -- Had no effect. 
2) Looked for the above mentioned kbdamsys.dll to no avail.
3) Disabled Anti-Virus -- Had no effect.
4) Destroyed Profile -- Had no effect.
5) Found risidual directories with firefox dlls from past beta / versions.
 5a) Wiped them out. 

Crashed 1 more time resulting in:

http://crash-stats.mozilla.com/report/index/4277b6ac-0e03-4113-bd80-bc1ba2090318?p=1

Firefox opened up but seemed sluggish. Checked out the Process manager. Firefox was consuming 1Gb RAM and 1.5GB VM Space. I killed it via the process manager. Upon restarting it did the same. This time I left it to work for about 20 minutes. Afterwhich I closed all open tabs and existed using the file menu. 
Firefox is, for the time being (fingers crossed), working fine. 

I'm writing here with hopes that something in the crash reports may help you. As a fellow developer I do appreciate all information I can get. I thank you for your time.

    
    

    
  
i've assume your malware is hexexbin.dll, submit it to some checker and destroy it.

    
    

    
  
(In reply to comment #134)
> The process I went about fixing it does not make sense

Well, it doesn't, but this is because you did a large number of things but didn't do the one thing you should have done - find Backdoor.Ulrbot.C.

From the reports, it's either hexexbin.dll (although it has one google hit) or mp3ixbmp.dll (which has none, makes it a bit more likely).

    
    

    
  
I upgraded from FF 3.0.11 to FF3.5 and found out that it crashed on start up every time. Safe Mode didnt work. Removing all old history off FF didnt help. The Pc is running vista 32 bit. Finally used the 'Run as administrator' option from the right click menu and it worked perfectly ! Can anyone tell me if there is a way around it?

    
    

    
  
(In reply to comment #138)
> I upgraded from FF 3.0.11 to FF3.5 and found out that it crashed on start up
> every time. Safe Mode didnt work. Removing all old history off FF didnt help.
> The Pc is running vista 32 bit. Finally used the 'Run as administrator' option
> from the right click menu and it worked perfectly ! Can anyone tell me if there
> is a way around it?

http://support.mozilla.com/en-US/kb/Firefox+crashes+when+you+open+it#Backdoor_Ulrbot_C

    
    

    
  
Here is some additional information that may help others to troubleshoot this issue and determine if it is related to Spector 360 or Spector Pro.  

The "System Event Dispatcher" service on Windows is really Spector 360.  If you stop this service, you disable the Spector 360 client on that workstation.  When the Spector client is installed on a workstation, a random name is chosen and used for the executable for this service.  If you do a "properties" on the "System Event Dispatcher", you'll see the name used by that particular client's Spector client service.  Sometimes it is shown as <random>.dll and other times <random>.exe.  Jotti.org identifies the Spector 360 client service as Backdoor_URLbot.

I'm currently having the same problem with FF3.52 crashing at launch.  Seems to be far worse than the 3.0.x version.  3.0.11 seemed to mostly work, although I would encounter random and frequent crashes.  Nothing I do for FF 3.52 seems to work.  Crashes everytime during launch, safe mode or not.  I've even tried disabling Spector 360, uninstalling FF3.52 and reinstalling with Spector disabled.  I'm running on Windows XP SP3.
Summary: startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] (causes: Backdoor.Ulrbot.C Trojan, Spector Pro) → Startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] (causes: Backdoor.Ulrbot.C Trojan, Spector Pro)

    
  
Blocks: malware-attacks

    
    

    
  
I have some news.Great news in my case.As i have already mentioned the company that i work uses spector and so i can only use firefox 3.0.15.
Until today.A colleague of mine found a solution.If i run the latest version of firefox(even minefield) by using Run As(windows xp) and choosing my username,it works!!!I hope this will help people monitored by spector.

    
    

    
  
I have heard reports from work that somehow Fx 3.6 does not break with our current version of Spector is installed.  Perhaps this is particular to the version we are using, but it might be worth a try for others in a similar situation, and it's easy enough to reinstall 3.0 if it still doesn't work for you.  I can't personally confirm, since I somehow got a working install of 3.5 on my system, and stopped worrying about it from then on :).

    
    

    
  
The crash signature for this in Firefox 4.0 is [@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ] 

eg. bp-629e5c46-0761-4303-a0c5-aee472110411
Summary: Startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] (causes: Backdoor.Ulrbot.C Trojan, Spector Pro) → Startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)] [@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ]  (causes: Backdoor.Ulrbot.C Trojan, Spector Pro)
Crash Signature: [@ nsDocShell::SetupNewViewer(nsIContentViewer*)]
[@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ]

    
    

    
  
This is still a valid crash. About 265 for all versions over the past month.
Crash Signature: [@ nsDocShell::SetupNewViewer(nsIContentViewer*)]
[@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ] → [@ nsDocShell::SetupNewViewer(nsIContentViewer*)]
[@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ]

    
  
Keywords: topcrash
Whiteboard: [malware-crash]
Assignee: cpearce → nobody

    
  
Crash Signature: [@ nsDocShell::SetupNewViewer(nsIContentViewer*)]
[@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ] → [@ nsDocShell::SetupNewViewer(nsIContentViewer*)]
[@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | DocumentViewerImpl::Close(nsISHEntry*) ]
[@ nsDocShell::SetupNewViewer]
[@ nsCOMPtr_base::assign_with_AddRef | DocumentViewerImpl::Close ]

    
    

    
  
Marking this as Resolved > Worksforme since there are no crashes with this signature reported in the last 6 months.


Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: