Crash in oxide::WebFrame::Destroy()

Bug #1450021 reported by Víctor R. Ruiz
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
Critical
Chris Coulson
1.7
Fix Released
Critical
Chris Coulson

Bug Description

With silo 26 installed, and oxide 1.7.4. Doing this, the webbrowser-app crashes:

Test case.
- Open webbrowser-app.
- Go to the following sites: www.iac.es, www.slashdot.org, www.elpais.com

Expected result.
- Sites are displayed correctly.

Actual result.
- Webbrowser crashes.

Tags: qa-silo
Revision history for this message
Víctor R. Ruiz (vrruiz) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :
Download full text (5.9 KiB)

This is the stacktrace extracted from Víctor’s crash file:

#0 size (this=0x14, this=0x14) at /usr/include/c++/4.9/bits/stl_vector.h:655
#1 GetChildCount (this=0x0) at ../../../../shared/browser/oxide_web_frame.cc:182
#2 oxide::WebFrame::WillDestroy (this=this@entry=0x0) at ../../../../shared/browser/oxide_web_frame.cc:52
#3 0xad1aa7a4 in oxide::WebFrame::Destroy (frame=0x0) at ../../../../shared/browser/oxide_web_frame.cc:157
#4 0xad404114 in content::WebContentsImpl::OnFrameRemoved (this=<optimized out>, render_frame_host=0xb791c3d8)
    at ../../../../third_party/chromium/src/content/browser/web_contents/web_contents_impl.cc:4504
#5 0xad2ad954 in Run (args#0=@0xbeeeeedc: 0xb791c3d8, this=<optimized out>)
    at ../../../../third_party/chromium/src/base/callback.h:396
#6 content::FrameTree::FrameRemoved (this=<optimized out>, frame=frame@entry=0xb7a11218)
    at ../../../../third_party/chromium/src/content/browser/frame_host/frame_tree.cc:347
#7 0xad2ae5b2 in content::FrameTreeNode::~FrameTreeNode (this=this@entry=0xb7a11218, __in_chrg=<optimized out>)
    at ../../../../third_party/chromium/src/content/browser/frame_host/frame_tree_node.cc:71
#8 0xad2ae84a in STLDeleteContainerPointers<__gnu_cxx::__normal_iterator<content::FrameTreeNode**, std::vector<content::FrameTreeNode*, std::allocator<content::FrameTreeNode*> > > > (end=..., begin=)
    at ../../../../third_party/chromium/src/base/stl_util.h:44
#9 STLDeleteElements<std::vector<content::FrameTreeNode*, std::allocator<content::FrameTreeNode*> > > (
    container=container@entry=0xb78fd5a4) at ../../../../third_party/chromium/src/base/stl_util.h:148
#10 0xad2ae66a in clear (this=0xb78fd5a4) at ../../../../third_party/chromium/src/base/memory/scoped_vector.h:99
#11 ~ScopedVector (this=0xb78fd5a4, __in_chrg=<optimized out>)
    at ../../../../third_party/chromium/src/base/memory/scoped_vector.h:38
#12 content::FrameTreeNode::~FrameTreeNode (this=this@entry=0xb78fd510, __in_chrg=<optimized out>)
    at ../../../../third_party/chromium/src/content/browser/frame_host/frame_tree_node.cc:70
#13 0xad2ae84a in STLDeleteContainerPointers<__gnu_cxx::__normal_iterator<content::FrameTreeNode**, std::vector<content::FrameTreeNode*, std::allocator<content::FrameTreeNode*> > > > (end=..., begin=)
    at ../../../../third_party/chromium/src/base/stl_util.h:44
#14 STLDeleteElements<std::vector<content::FrameTreeNode*, std::allocator<content::FrameTreeNode*> > > (
    container=container@entry=0xbeeef078) at ../../../../third_party/chromium/src/base/stl_util.h:148
#15 0xad2ae8d6 in clear (this=0xbeeef078) at ../../../../third_party/chromium/src/base/memory/scoped_vector.h:99
#16 content::FrameTreeNode::ResetForNewProcess (this=<optimized out>)
    at ../../../../third_party/chromium/src/content/browser/frame_host/frame_tree_node.cc:134
#17 0xad2ad0d2 in content::FrameTree::ResetForMainFrameSwap (this=0xb795d898)
    at ../../../../third_party/chromium/src/content/browser/frame_host/frame_tree.cc:217
#18 0xad3905ae in content::RenderViewHostImpl::AttachToFrameTree (this=<optimized out>)
    at ../../../../third_party/chromium/src/content/browser/renderer_host/render_view_host_impl.cc:1386
---Type <return> ...

Read more...

summary: - Oxide crash
+ Crash in oxide::WebFrame::Destroy()
Revision history for this message
Olivier Tilloy (osomon) wrote :

I can now reproduce the crash, and I’m getting the exact same stack trace.

Changed in oxide:
importance: Undecided → Critical
status: New → Confirmed
Revision history for this message
Olivier Tilloy (osomon) wrote :

And I’m also reproducing the exact same crash with 1.7.3, so I confirm it’s not a regression introduced by 1.7.4.

Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
milestone: none → branch-1.8
status: Confirmed → Fix Released
Revision history for this message
Chris Coulson (chrisccoulson) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.