Closed Bug 679846 Opened 13 years ago Closed 2 years ago

crash _SEH_epilog4 (Malware related?)

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
6 Branch
Platform:
All
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED INACTIVE
Tracking Flags:
Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
firefox-esr45 --- affected

People

(Reporter: marcia, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is report bp-262b00d0-a2ba-411f-8c6f-2a1922110816 . ============================================================= Seen while looking at crash stats. https://crash-stats.mozilla.com/report/list?signature=_SEH_epilog4 to the crashes which are all Windows and seen across all versions. No correlations are available and comments mention a bunch of different sites. Maybe some URLs would help here. Frame Module Signature [Expand] Source 0 ntdll.dll ZwWaitForSingleObject 1 ntdll.dll ZwWaitForSingleObject 2 KERNELBASE.dll _SEH_epilog4 3 kernel32.dll WaitForSingleObjectExImplementation 4 kernel32.dll WaitForSingleObject 5 xul.dll google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:763 6 xul.dll google_breakpad::ExceptionHandler::HandleException toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:520 7 msvcr71.dll __CxxUnhandledExceptionFilter 8 kernel32.dll SbpMergeApphackContexts 9 ntdll.dll RtlKnownExceptionFilter 10 ntdll.dll ?? ::FNODOBFM::`string' 11 ntdll.dll _RtlUserThreadStart
Here are some URLs that are specific to 6.0, although nothing really stands out: 63 \N 27 8 http://mozilla.jp/firefox/ 2 http://www.mozilla.com/en-US/firefox/6.0/whatsnew/ 2 http://i.g-fox.cn/ 1 wyciwyg://26/http://os.cloudme.com/ 1 jar:file:///S:/STATION3_D/Program%20files/FirefoxPortable%20v6.0%20%5B16-8-2011%5D/App/firefox/omni.jar!/chrome/browser/content/browser/aboutHome.xhtml 1 http://xsellize.com/topic/154049-request-garmin-n-america-appstore/ 1 http://www.youtube.com/profile?annotation_id=annotation_267769&user=Shooteerman&feature=iv 1 http://www.youngamerica.com/product/343693/8250005M2/_/all%26%23160%3Bseasons%3Cbr%3Edresser/Age/preschool 1 http://www.video247.tv/media.php?page=http://videos.desihome.info/daily/jihne/part4.php 1 http://www.tgu.edu.vn/Pages/TGU/TopicDetail/337 1 http://www.sedotmini.com/tag/one-piece/page/7/ 1 http://www.pracuj.pl/praca/grafik;kw/mazowieckie;r,7 1 http://www.mozilla.jp/firefox/ 1 http://www.mozilla.com/firefox/ 1 http://www.mediafire.com/?fkd0vjb4t7d 1 http://www.intel.com/it_IT/products/processor/corei7/mobile/index.htm 1 http://www.hao123.com/ 1 http://www.google.co.jp/search?q=easus&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-a 1 http://www.filehippo.com/download_flashplayer_ie/ 1 http://www.facebook.com/home.php?ref=home 1 http://www.facebook.com/ 1 http://www.demonoid.me/donate.php 1 http://www.cneurope.de/howto/tutorials 1 http://www.btalah.com/showthread.php?t=345445 1 http://update.filehippo.com/update/check/8e0d519b-52d9-477c-aa81-015e1cc9c285/nobeta 1 http://tr-tr.facebook.com/ 1 http://trac.webkit.org/wiki/QtWebKitFeatures22 1 https://www.facebook.com/profile.php
Keywords: needURLs
In crash automation a particular url http://www.emol.com/noticias/deportes/2011/08/11/497292/prensa-internacional-la-entrada-de-alexis-sanchez-relanzo-a-chile.html is associated with _SEH_epilog4 in Socorro but I get a different stack like moz_free | operator delete[](void*) nsHtml5UTF16Buffer::~nsHtml5UTF16Buffer() nsHtml5UTF16Buffer::`scalar deleting destructor'(unsigned int) + 0xe nsHtml5UTF16Buffer::Release() nsRefPtr<nsHtml5UTF16Buffer>::~nsRefPtr<nsHtml5UTF16Buffer>() see bug 577952 I wonder if the SocorroStack above is more related to the breakpad processor falling over trying to process the stack overflow. Marcia, my windows vms are tied up at the moment. Can you check if this sends a _SEH_epilog4 in a nightly build?
bc: I tried that site with Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110818 Firefox/9.0a1 in a Win XP VM and did not get a crash. After my mtg will head down to the lab and test on some real hardware down there.
bc: Using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110818 Firefox/9.0a1 in the lab, I cannot reproduce the crash either at that site.
Marcia: neither can I with nightly Nightly builds or debug Nightly just loading the site. I do crash when I load it in the Spider extension though. Not sure if that is a real bug or not.
Someone mentioned in bug 467169 that the testcase there was crashing with this stack. But I see all kinds of breakpad stuff on this stack. Is that correct behavior?
It's sort of an unfortunate implementation detail of Breakpad. We're handling a C++ exception of some sort here, not an actual "crash" as far as the OS is concerned, so we can't present the stack starting at the point of the crash. In the stack in comment 0 here, for example, the actual crash is somewhere below this frame: 7 msvcr71.dll __CxxUnhandledExceptionFilter
A startup crash at http://crash-stats.mozilla.com/report/index/f910f8de-f977-43b2-8d31-d7df82110825 had a randomly named .dll file at the top of the module list, and in IRC the user mentioned a Malware Bytes full scan and a scan with another anti-virus failed to show any malware up. I got him to scan with http://www.microsoft.com/security/scanner/en-us/default.aspx and Trojan Win32/Sefrit.O was detected and removed, and Firefox started working immediately
Summary: crash _SEH_epilog4 → crash _SEH_epilog4 (Malware related?)
I've had a couple crashes on my home machine with _SEH_epilog4 in the signature. The last one was a few minutes ago, on the latest 7 beta channel release. I have Microsoft Security Essentials installed and running and am pretty sure I don't have any malware on my system. The last 2 times I've seen this crash, a page had loaded and I did the normal scroll around for a few seconds and then all of a sudden, crash report window. This latest time, I was moving the cursor into a <code> block to perform a highlight and copy. Not sure if I got the mouse click in before it crashed. My latest crash is https://crash-stats.mozilla.com/report/index/bp-805afd4f-cb3c-42b8-a976-0ac6b2110922. The URL that triggered was http://docs.disqus.com/developers/universal/. Unfortunately, it didn't reproduce. Former crashes are: https://crash-stats.mozilla.com/report/index/bp-74ec5dcd-a830-4ee2-bb3d-157d62110922 https://crash-stats.mozilla.com/report/index/bp-cf23fdd3-c71b-40e3-b355-37aa82110916
Gregory: after poking at your minidumps, I've found that this signature is bogus. Your dumps are being misprocessed because of bug 683162, which hasn't been rolled out into production yet. When that gets landed we can reprocess your dumps, and they'll all have different, more useful signatures. (More concretely: the version of Breakpad in production can't read the exception context in your dumps, so it just starts walking from the very top of the thread stack, and never gets anywhere useful.)
I've been seeing this since I updated to yesterday's nightly (afe75f8431ad -- 20110925). My previous nightly was perhaps two weeks ago. Example crash: https://crash-stats.mozilla.com/report/index/bp-a2dbfe18-a3ed-48e9-8d2d-d50192110926 bugzilla URLs (on a different non-mozilla bugzilla) seem to trigger it, but that's all I tend to view in that profile. Oddly, I have yet to see it in my main profile where I do most of my browsing. Ted, do all of our crashes suffer from the reporting problem, or just Gregory's? It looks to me like they do, but not sure why you singled out his dumps :)
Oh -- and I'm crashing on x86-32, not -64.
Hardware: x86_64 → All
This is likely to affect all crashes on Windows 7 SP1 on recent Intel processors. Microsoft added a new flag bit to the CPU context structure on W7SP1 to indicate that Intel AVX CPU state is being stored, which broke a Breakpad assumption. The result is that Breakpad fails to walk the crashing thread properly. (It starts at the very top of the stack, inside the Breakpad handler code instead of at the point of the exception.)
I singled out his dumps because I actually downloaded them and checked for the presence of the new flag which was breaking us, FWIW. I am speculating about your dumps, but I'm fairly confident that's the issue.
Ted: I don't suppose you have the actual stack traces of my crashes? How difficult would it be to teach me to fish so I can compute them myself?
I filed bug 689579 to get crashes with this signature reprocessed, so when that's fixed you should be able to reload them and get the correct stack out.
Crash volume for signature '_SEH_epilog4': - nightly (version 50): 0 crash from 2016-06-06. - aurora (version 49): 1 crash from 2016-06-07. - beta (version 48): 13 crashes from 2016-06-06. - release (version 47): 56 crashes from 2016-05-31. - esr (version 45): 5 crashes from 2016-04-07. Crash volume on the last weeks: Week N-1 Week N-2 Week N-3 Week N-4 Week N-5 Week N-6 Week N-7 - nightly 0 0 0 0 0 0 0 - aurora 0 0 0 1 0 0 0 - beta 2 6 0 0 0 3 0 - release 9 9 9 4 8 11 2 - esr 2 0 2 0 1 0 0 Affected platform: Windows
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox-esr45: --- → affected
QA Whiteboard: qa-not-actionable

Hey Gankra, is there anything actionable here? Kinda digging through the comments, I think part of the issue here had to do with us mangling crash reports because of the old minidump processing stuff... but I think that's since been fixed. Do we have anything to do here, or any useful information to point us at the right component to place this in?

Flags: needinfo?(a.beingessner)

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: critical → S3
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.