renderer crash on raspberry pi 3 #334
Answered
by
jameshilliard
jameshilliard
asked this question in
Q&A
-
I'm seeing this renderer crash on a raspberry pi 3. (cog:921): Cog-Core-WARNING **: 05:57:30.135: <app:///> Crash!: The renderer process crashed. Reloading the page may fix intermittent failures.
--921-- REDIR: 0xb21d1d0 (libstdc++.so.6:operator delete(void*)) redirected to 0x484f064 (operator delete(void*))
==921== Invalid read of size 4
==921== at 0xB158C74: WS::Instance::unregisterSurface(WS::Surface*) (ws.cpp:551)
==921== by 0xB158CC7: operator() (ws.cpp:157)
==921== by 0xB158CC7: WS::s_compositorInterface::{lambda(wl_client*, wl_resource*, unsigned int)#1}::operator()(wl_client, wl_resource, unsigned int) const::{lambda(wl_resource)#1}::_FUN(wl_resource) (ws.cpp:159)
==921== by 0xB944F83: destroy_resource (wayland-server.c:724)
==921== by 0xB94916B: for_each_helper (wayland-util.c:372)
==921== by 0xB9496BF: wl_map_for_each (wayland-util.c:385)
==921== by 0xB945107: wl_client_destroy (wayland-server.c:883)
==921== by 0xB9451DB: wl_client_connection_data (wayland-server.c:337)
==921== by 0xB947033: wl_event_loop_dispatch (event-loop.c:1027)
==921== by 0xB157BEB: operator() (ws.cpp:75)
==921== by 0xB157BEB: WS::ServerSource::{lambda(_GSource*, int (*)(void*), void*)#3}::_FUN(_GSource*, int (*)(void*), void*) (ws.cpp:84)
==921== by 0x80F91A3: g_main_dispatch (gmain.c:3337)
==921== by 0x80F91A3: g_main_context_dispatch (gmain.c:4055)
==921== by 0x80F9403: g_main_context_iterate.constprop.0 (gmain.c:4131)
==921== by 0x80F94EB: g_main_context_iteration (gmain.c:4196)
==921== Address 0x50810ea8 is 8 bytes inside a block of size 24 free'd
==921== at 0x484F0E8: operator delete(void*) (vg_replace_malloc.c:802)
==921== by 0xB15900F: deallocate (new_allocator.h:133)
==921== by 0xB15900F: deallocate (alloc_traits.h:492)
==921== by 0xB15900F: _M_deallocate_node_ptr (hashtable_policy.h:2064)
==921== by 0xB15900F: _M_deallocate_node (hashtable_policy.h:2054)
==921== by 0xB15900F: _M_erase (hashtable.h:1888)
==921== by 0xB15900F: std::_Hashtable<unsigned int, std::pair<unsigned int const, WS::Surface*>, std::allocator<std::pair<unsigned int const, WS::Surface*> >, std::__detail::_Select1st, std::equal_to<unsigned int>, std::hash<unsigned int>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::erase(std::__detail::_Node_const_iterator<std::pair<unsigned int const, WS::Surface*>, false, false>) (hashtable.h:1863)
==921== by 0xB158C8F: erase (hashtable.h:807)
==921== by 0xB158C8F: erase (unordered_map.h:797)
==921== by 0xB158C8F: WS::Instance::unregisterSurface(WS::Surface*) (ws.cpp:549)
==921== by 0xB158CC7: operator() (ws.cpp:157)
==921== by 0xB158CC7: WS::s_compositorInterface::{lambda(wl_client*, wl_resource*, unsigned int)#1}::operator()(wl_client, wl_resource, unsigned int) const::{lambda(wl_resource)#1}::_FUN(wl_resource) (ws.cpp:159)
==921== by 0xB944F83: destroy_resource (wayland-server.c:724)
==921== by 0xB94916B: for_each_helper (wayland-util.c:372)
==921== by 0xB9496BF: wl_map_for_each (wayland-util.c:385)
==921== by 0xB945107: wl_client_destroy (wayland-server.c:883)
==921== by 0xB9451DB: wl_client_connection_data (wayland-server.c:337)
==921== by 0xB947033: wl_event_loop_dispatch (event-loop.c:1027)
==921== by 0xB157BEB: operator() (ws.cpp:75)
==921== by 0xB157BEB: WS::ServerSource::{lambda(_GSource*, int (*)(void*), void*)#3}::_FUN(_GSource*, int (*)(void*), void*) (ws.cpp:84)
==921== by 0x80F91A3: g_main_dispatch (gmain.c:3337)
==921== by 0x80F91A3: g_main_context_dispatch (gmain.c:4055)
==921== Block was alloc'd at
==921== at 0x484CD80: operator new(unsigned long) (vg_replace_malloc.c:417)
==921== by 0xB15810B: allocate (new_allocator.h:115)
==921== by 0xB15810B: allocate (alloc_traits.h:460)
==921== by 0xB15810B: _M_allocate_node<std::pair<unsigned int const, WS::Surface*> > (hashtable_policy.h:2032)
==921== by 0xB15810B: _Scoped_node<std::pair<unsigned int const, WS::Surface*> > (hashtable.h:272)
==921== by 0xB15810B: _M_emplace<std::pair<unsigned int const, WS::Surface*> > (hashtable.h:1673)
==921== by 0xB15810B: insert<std::pair<unsigned int const, WS::Surface*> > (hashtable_policy.h:1021)
==921== by 0xB15810B: insert (unordered_map.h:586)
==921== by 0xB15810B: WS::Instance::registerSurface(unsigned int, WS::Surface*) (ws.cpp:407)
==921== by 0xB4CC7A7: ffi_call_SYSV (sysv.S:114)
==921== by 0xB4CBFCF: ffi_call_int (ffi.c:747)
==921== by 0xB9482C3: wl_closure_invoke (connection.c:1018)
==921== by 0xB945443: wl_client_connection_data (wayland-server.c:432)
==921== by 0xB947033: wl_event_loop_dispatch (event-loop.c:1027)
==921== by 0xB157BEB: operator() (ws.cpp:75)
==921== by 0xB157BEB: WS::ServerSource::{lambda(_GSource*, int (*)(void*), void*)#3}::_FUN(_GSource*, int (*)(void*), void*) (ws.cpp:84)
==921== by 0x80F91A3: g_main_dispatch (gmain.c:3337)
==921== by 0x80F91A3: g_main_context_dispatch (gmain.c:4055)
==921== by 0x80F9403: g_main_context_iterate.constprop.0 (gmain.c:4131)
==921== by 0x80F94EB: g_main_context_iteration (gmain.c:4196)
==921== by 0x7F5AFEF: g_application_run (gapplication.c:2560)
==921== |
Beta Was this translation helpful? Give feedback.
Answered by
jameshilliard
Jul 24, 2021
Replies: 2 comments
-
Moving this to #166 since it appears to be originating from WPEBackend-fdo. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Ok, was wrong about it being in WPEBackend-fdo. Backporting WebKit/WebKit@05f6ba8 fixes this crash. As I suspected(since it wasn't crashing on x86_64) it's an aarch64 specific bug. |
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
philn
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ok, was wrong about it being in WPEBackend-fdo. Backporting WebKit/WebKit@05f6ba8 fixes this crash. As I suspected(since it wasn't crashing on x86_64) it's an aarch64 specific bug.