Closed Bug 484458 Opened 15 years ago Closed 15 years ago

body onload="alert(1)" crashes Firefox after reload

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
1.9.0 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: brewsterdesigns, Assigned: karlt)

References

Details

(Keywords: crash, testcase, verified1.9.0.11, Whiteboard: [sg:dupe 451341][fixed in bug 451341])

Attachments

(2 files)

backtrace core dump
10.87 KB, text/plain
Details
testcase based on comments
268 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030422 Ubuntu/8.10 (intrepid) Firefox/3.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030422 Ubuntu/8.10 (intrepid) Firefox/3.0.7

Including ANY javascript in the body onload attribute causes Firefox to crash when reloaded a few times. Original problem was I had a page which opened another page in a new window that printed automatically (onload="window.print() ). If I reloaded that page, firefox would immediately crash. This was reproducible every time.

Reproducible: Always

Steps to Reproduce:
1) Create html page with dynamic content such as below php:
<html>
<body onload="window.alert('a')">
<?=rand(0,100);?>
</body>
</html>

2) Have some javascript run for the body onload event (alert() or print() )

3) Load the page, wait 10 seconds, press reload. Repeat until crashes - usually only takes 1 or 2 times..

Actual Results:  
Firefox crashes immediately

Expected Results:  
The page to load normally


In my tests the actual javascript is irrelevant. The dynamic content seems important. Waiting the 5-10 seconds between reloads seems important (maybe when the cache expires or something??)

Reproducible on multiple computers, including fresh install of ubuntu 8.10 and latest firefox.
Component: General → DOM: Core & HTML
Keywords: crash, testcase-wanted
Product: Firefox → Core
QA Contact: general → general
So far haven't been able to reproduce using 1.9.0.x.
But I'm not sure I'm using the right testcase:
<html>
<body onload="window.alert('a')">
alert test
</body>
</html>

Is the <?=rand(0,100);?> relevant here?

Are you using Firefox downloaded from Mozilla, or build provided by
Ubuntu?
The random content will be generated by the server so what Firefox gets should be equivalent to the statis text in comment 1, but maybe it triggers PHP to send different headers that are relevant to this bug.

It might be headers specific to your server setup, even. Could you give us a link to a test page that you see the problem with?
This issue might be related to Linux, I can reproduce this on Foresight Linux (Firefox 3.0.7) and Fedora 10 (Firefox 3.0.7).

I'm using the following local file /tmp/test.html:
<html>
<body onload="window.alert('a')">
</body>
</html>

And opened firefox using:
firefox /tmp/test.html

Using a 10 sec interval reload (Ctrl-R) will crash firefox in about 2 tries.
(In reply to comment #1)
> So far haven't been able to reproduce using 1.9.0.x.
This testing was done one a Fedora-based x86_64 Linux.

Will test on 32bit Fedora 10.
please install debug symbols, ubuntu has them somewhere...
I can reproduce this on Fedora 10.
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → Widget: Gtk
Ever confirmed: true
QA Contact: general → gtk
Though, perhaps this is a regression in gtk2.
Attached file backtrace core dump — 
This is a backtrace from gdb by using a core dump.
Thanks for the helpful backtrace.
This has the same cause (and fix) as bug 451341.

The crash is trying to AddRef an nsWindow.

0x00000000000002f1 in ?? ()
(gdb) up
#1  0x00007f06c4fbfaa1 in nsRefPtr (this=0x7fffdada9000, aRawPtr=0x247c420)
    at ../../../dist/include/xpcom/nsAutoPtr.h:980
980                 mRawPtr->AddRef();
(gdb) up
#2  0x00007f06c4fbac08 in leave_notify_event_cb (widget=0x20bfaa0,
    event=0x2d60c20)
    at /home/karl/moz/cvs/mozilla/widget/src/gtk2/nsWindow.cpp:4636
4636        nsRefPtr<nsWindow> window = get_window_for_gdk_window(event->window);

The nsWindow comes from a destroyed (but not deleted) GdkWindow.

(gdb) p event->window
$1 = (GdkWindow *) 0x2c98000
(gdb) p *(GdkWindowObject*)event->window
$2 = {parent_instance = {parent_instance = {g_type_instance = {
        g_class = 0x1f52dd0}, ref_count = 3, qdata = 0x2d53e00}},
  impl = 0x2c980a0, parent = 0x0, user_data = 0x0, x = 0, y = 0,
  extension_events = 0, filters = 0x0, children = 0x0, bg_color = {pixel = 0,
    red = 0, green = 0, blue = 0}, bg_pixmap = 0x2, paint_stack = 0x0,
  update_area = 0x0, update_freeze_count = 0, window_type = 2 '\002',
  depth = 24 '\030', resize_count = 0 '\0',
  state = GDK_WINDOW_STATE_WITHDRAWN, guffaw_gravity = 0, input_only = 0,
  modal_hint = 0, composited = 0, destroyed = 1, accept_focus = 1,
  focus_on_map = 1, shaped = 0, event_mask = 176902,
  update_and_descendants_freeze_count = 0, redirect = 0x0}
(gdb) p event->window->parent_instance.qdata
$3 = (GData *) 0x2d53e00
gdb) x /4a 0x2d53e00
0x2d53e00:      0x299bfa0       0x33
0x2d53e10:      0x2a7ff40       0x7f06cec480ca <weak_refs_notify>
(gdb) x /4a 0x299bfa0
0x299bfa0:      0x2956c80       0x34b
0x299bfb0:      0x2975200       0x0
(gdb) p ((char*(*)())g_quark_to_string)(0x34b)
[Thread 0x5d5a6950 (LWP 5461) exited]
$4 = 0x2351c80 "mozdrawingarea"
(gdb) x /4a 0x2956c80
0x2956c80:      0x0     0x34a
0x2956c90:      0x247c420       0x0
(gdb) p ((char*(*)())g_quark_to_string)(0x34a)
$5 = 0x2351030 "nsWindow"

The nsWindow looks like it has been destroyed, and most likely deleted too
(though mRefCnt is still 1 due to Mozilla's ref counting leaving a refcnt
of 1 on deleted objects.
http://hg.mozilla.org/mozilla-central/annotate/7348ed185ae2/xpcom/glue/nsISupportsImpl.h#l311)

(gdb) p *(nsWindow*)0x247c420
$6 = {<nsCommonWidget> = {<nsBaseWidget> = {<nsIWidget> = {<nsISupports> = {
          _vptr.nsISupports = 0x2d23780}, mFirstChild = {
          mRawPtr = 0x7f06cddb1d40}, mLastChild = 0x0, mNextSibling = {
          mRawPtr = 0x0}, mPrevSibling = 0x0}, mRefCnt = {mValue = 1},
      _mOwningThread = {mThread = 0x1f2aa20}, mClientData = 0x0,
      mEventCallback = 0x7f06c26f97ea <HandleEvent>, mContext = 0x0,
      mToolkit = 0x0, mMouseListener = 0x0, mEventListener = 0x0,
      mBackground = 36073648, mForeground = 0, mCursor = eCursor_standard,
      mWindowType = eWindowType_child, mBorderStyle = eBorderStyle_default,
      mIsShiftDown = 0 '\0', mIsControlDown = 0 '\0', mIsAltDown = 0 '\0',
      mIsDestroying = 0 '\0', mOnDestroyCalled = 1 '\001', mBounds = {x = 0,
        y = 0, width = 1091, height = 605}, mOriginalBounds = 0x0,
      mZIndex = 0, mSizeMode = nsSizeMode_Normal}, mParent = {mRawPtr = 0x0},
    mIsTopLevel = 0 '\0', mIsDestroyed = 1 '\001', mNeedsResize = 0 '\0',
    mNeedsMove = 0 '\0', mListenForResizes = 0 '\0', mIsShown = 1 '\001',
    mNeedsShow = 0 '\0', mEnabled = 1, mCreated = 0, mPlaced = 1,
    mPreferredWidth = 0,
    mPreferredHeight = 0}, <nsSupportsWeakReference> = {<nsISupportsWeakReference> = {<nsISupports> = {_vptr.nsISupports = 0x7f06d18c3770}, <No data fields>},
    mProxy = 0x0}, <nsIKBStateControl> = {<nsISupports> = {
      _vptr.nsISupports = 0x7f06c5239aa0}, <No data fields>},
  mOldFocusWindow = 0, mIMEData = 0x0, mShell = 0x0, mContainer = 0x0,
  mDrawingarea = 0x0, mWindowGroup = 0x0, mContainerGotFocus = 0,
  mContainerLostFocus = 0, mContainerBlockFocus = 0, mIsVisible = 1,
  mRetryPointerGrab = 0, mActivatePending = 0, mRetryKeyboardGrab = 0,
  mTransientParent = 0x0, mSizeState = 0,
  mPluginType = nsWindow::PluginType_NONE, mTransparencyBitmapWidth = 0,
  mTransparencyBitmapHeight = 0, mThebesSurface = {mRawPtr = 0x0},
  mRootAccessible = {mRawPtr = 0x0}, mIsTransparent = 0,
  mTransparencyBitmap = 0x0, mDragMotionWidget = 0x0,
  mDragMotionContext = 0x0, mDragMotionX = 0, mDragMotionY = 0,
  mDragMotionTime = 0, mDragMotionTimerID = 0, mDragLeaveTimer = {
    mRawPtr = 0x0}, mKeyDownFlags = {0, 0, 0, 0, 0, 0, 0, 0}}
Assignee: nobody → mozbugz
Depends on: 451341
Version: unspecified → 1.9.0 Branch
Group: core-security
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.10+
Whiteboard: [sg:dupe 451341]
This testcase is based on the description in the comments, but I can't test the crash on my mac. If this doesn't reproduce the crash for those who have been able to see it please let me know so we can mark this obsolete and try again. Hopefully meta-refresh isn't any different than a manual Ctrl-r for this case -- keyboard events don't seem to be involved anywhere.
The testcase indeed aborts Firefox on Fedora 10.
The crash is only reproducible if the pointer is over the child window for the document (as it is likely to be after clicking the alert).  The crash doesn't occur when the mouse is over any chrome around the document.
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.9.0.10
Resolution: --- → FIXED
Whiteboard: [sg:dupe 451341] → [sg:dupe 451341][fixed in bug 451341]
It doesn't affect 1.8 line.
Flags: wanted1.8.1.x-
Verified fixed in 1.9.0.11 with  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11pre) Gecko/2009051104 GranParadiso/3.0.11pre. I verified the crash with 1.9.0.10 first.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.11 → verified1.9.0.11
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: