Closed Bug 493279 Opened 15 years ago Closed 14 years ago

Breakpoint [@ oggz_close]

Categories

(Core :: Audio/Video, defect)

1.9.1 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cbook, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090515 Shiretoko/3.5b5pre 

Steps to reproduce:
-> Loaded http://box.zhangmen.baidu.com/m?gate=1&ct=134217728&tn=baidumt,%C9%CB%D7%B7%C8%CB%20%20&word=wma,http://hhspot.hkfyg.org.hk/nmMz.wma,,[%C9%CB%D7%B7%C8%CB]&si=%C9%CB%D7%B7%C8%CB;;%B9%C5%BE%DE%BB%F9;;24418;;24418&lm=16777216&mtid=1&d=9 and left the vm idle, after i while i got this crash report.

It seems that this crash randomly. Also in an earlier run this was reported as exploitable problem : EXPLOITABLE: Exploitable - User Mode Write AV starting at Unknown Symbol @ 0x6d89c0006d89c (Hash=0x766e4927.0x57562160), which might be related to bug 493243

(8c8.a74): Break instruction exception - code 80000003 (!!! second chance !!!)
eax=00000001 ebx=7ffd8000 ecx=937b4f91 edx=00000037 esi=00cea9e0 edi=7c910222
eip=10202c23 esp=0012e6b4 ebp=0012e6cc iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0
MSVCR80D!get_pgmptr+0x1c3:
10202c23 cc              int     3

Exploitability Classification: UNKNOWN
Recommended Bug Title: Breakpoint starting at MSVCR80D!get_pgmptr+0x1c3 (Hash=0x1b336a32.0x1c360a27)

While a breakpoint itself is probably not exploitable, it may also be an indication that an attacker is testing a target. In either case breakpoints should not exist in production code.
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0012e6cc 10223adb MSVCR80D!get_pgmptr+0x1c3
0012ea08 102199af MSVCR80D!abort+0x2b
0012f908 030f0987 MSVCR80D!wassert+0x2ef
0012f91c 030ea71f gklayout!oggz_close+0x97
0012f92c 030dc93f gklayout!oggplay_close+0x7f
0012f948 030dc8bf gklayout!nsOggDecodeStateMachine::~nsOggDecodeStateMachine+0x5f
0012f954 00296170 gklayout!nsOggDecodeStateMachine::`scalar deleting destructor'+0xf
0012f970 030e170b xpcom_core!nsRunnable::Release+0x90
0012f984 030e15f7 gklayout!nsCOMPtr<nsOggDecodeStateMachine>::assign_assuming_AddRef+0x5b
0012f994 030e0f33 gklayout!nsCOMPtr<nsOggDecodeStateMachine>::assign_with_AddRef+0x27
0012f9a4 030dfc06 gklayout!nsCOMPtr<nsOggDecodeStateMachine>::operator=+0x13
0012f9b4 00304d1a gklayout!nsDestroyStateMachine::Run+0x76
0012f9f0 00296783 xpcom_core!nsThread::ProcessNextEvent+0x1fa
0012fa0c 01dbf72d xpcom_core!NS_ProcessNextEvent_P+0x53
0012fa20 01fd42db gkwidget!nsBaseAppShell::Run+0x5d
0012fa34 1000cfd7 tkitcmps!nsAppStartup::Run+0x6b
0012fed0 00401ac2 xul!XRE_main+0x2fb7
0012ff34 00401289 firefox!NS_internal_main+0x2b2
0012ff68 00402746 firefox!wmain+0x119
0012ffb8 0040259d firefox!__tmainCRTStartup+0x1a6
quit:
Flags: blocking1.9.1?
Keywords: crash
Whiteboard: [sg:critical?]
tried on mac.  not able to reproduce, but I don't have a WMP plugin.  I'll get one and try again.
still no crash for me on mac after installing Flip4Mac Windows Media Plugin 2.2.2 and geting some music to play from the site.

tomcat, what version of wpm are you running?
(In reply to comment #2)
> still no crash for me on mac after installing Flip4Mac Windows Media Plugin
> 2.2.2 and geting some music to play from the site.
> 
> tomcat, what version of wpm are you running?

wpm: 11 - version: 11.0.5721.5260

I think Bob saw this crash too.
Actually, on looking at it again I don't think I did. This may be windows only re MSVCR80. I couldn't reproduce with a slightly old 1.9.1/1.9.2 build on Windows. Rebuilding now to double check.
running that same wpm 11 version in comment 3 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090515 Minefield/3.6a1pre  I haven't seen the crash yet.
The stacktrace has ogg related code in it, which is weird, because that site doesn't use ogg files.
chris double ought to at least have a look at that strangeness in the stack.

tomcat?  any chance the test vm loaded some ogg content before it loaded this page, the hit the random crash?   

maybe that ogg strangness is the part that the rest of us can't reproduce
Component: General → Video/Audio
QA Contact: general → video.audio
Yes. that looks strange. The only way that code should be in the stack is if a video element was used with a src set to something served with an ogg mime type.
Actually not quite true, it'll also be there if an object element is used pointing to an Ogg file.
Summary: Breakpoint starting at MSVCR80D!get_pgmptr+0x1c3 → Breakpoint [@ oggz_close]
This stack is a safe abort. I don't really want to block on this, but I'd love to get it fixed if we can get a decent testcase.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
How easy is it to reproduce this, and is that (or any) Ogg code in the stack every time?  Is it still reproducible if the media.ogg.enabled pref is set to false (you need to restart after changing the pref)?
I haven't been able to reproduce on Mac or a  WinXP VM.  Tomcat might be the only one that's produced it so far.

I checked the crash-stats database for any signatures or comments that had "oggz_close"  in the reports submitted last week and found nothing.  

But oggz_close isn't listed in the top of the stack or the signature we generate in the crash reporter and the "WARNING: Stack unwind information not available. Following frames may be wrong." makes it a bit hard to find in the current set of crash analysis tools we have right now.
had the database guys do a bit deeper search of 3.5b4 data

the string 'oggz_close' does not appear in the top 10 frames of any crash in  a copy of the crash database with the date range of 2009-05-11 through 2009-05-17
This is not sg:critical, it's a safe abort.
Whiteboard: [sg:critical?]
Marking not-exploitable per comment 14 (and comment 10).
Whiteboard: [sg:nse]
Actually, makes more sense to un-hide.
Group: core-security
Whiteboard: [sg:nse]
We've removed libogg{z,play} so this cannot happen on 3.7a+ anymore. It still can happen on 1.9.1 and 1.9.2 of course.
Might as well close this.  The code has been removed from trunk, and there are no plans to track this down on the branches AFAIK.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Crash Signature: [@ oggz_close]
You need to log in before you can comment on or make changes to this bug.