SIGABRT with 3.2171.1979 on Linux

[dliw]

Hello,
after updating a minimal application using GTK2 and CEF from version 3.1750 to 3.2171, I get the following crash:

free(): invalid pointer: 0x00001d18c8742000 ***
Program received signal SIGABRT, Aborted.
0x00007ffff56ff187 in raise () from /lib64/libc.so.6

This crash seems to happen, when things have to be redraw eg. when resizing, calling Frame->loadUrl, ...

Some more information:
- I'm calling cef_do_message_loop_work within a gtk main loop, but the same crash happens with cef_run_message_loop, too.
- release libcef.so is used, the debug one crashes with

Code: Select all

memory allocation bug: object at 0x7fffe7f60ec0 has never been allocated
Program received signal SIGSEGV, Segmentation fault.
tcmalloc::Abort() () at ../../third_party/tcmalloc/chromium/src/base/abort.cc:15


- the program is written in Pascal, therefore I only use the C api
- sandbox is disabled

The full backtrace looks like this:
(gdb) backtrace
#0 0x00007ffff56ff187 in raise () at /lib64/libc.so.6
#1 0x00007ffff5700538 in abort () at /lib64/libc.so.6
#2 0x00007ffff573d0c4 in () at /lib64/libc.so.6
#3 0x00007ffff574292e in malloc_printerr () at /lib64/libc.so.6
#4 0x00007fffe4b3b125 in SkMallocPixelRef::~SkMallocPixelRef() () at ./libcef.so
#5 0x00007fffe4afd12f in SkBitmap::~SkBitmap() () at ./libcef.so
#6 0x00007fffe4b007e7 in SkBitmapDevice::~SkBitmapDevice() () at ./libcef.so
#7 0x00007fffe4b1c640 in SkCanvas::internalRestore() () at ./libcef.so
#8 0x00007fffe4b1c467 in SkCanvas::~SkCanvas() () at ./libcef.so
#9 0x00007fffe491b6d9 in SkCanvas::~SkCanvas() () at ./libcef.so
#10 0x00007fffe5f7a376 in cc::BitmapContentLayerUpdater::PrepareToUpdate(gfx::Size const&, gfx::Rect const&, gfx::Size const&, float, float) () at ./libcef.so
#11 0x00007fffe5f4fa7d in cc::TiledLayer::UpdateTileTextures(gfx::Rect const&, gfx::Rect const&, int, int, int, int, cc::ResourceUpdateQueue*, cc::OcclusionTracker<cc::Layer> const*) () at ./libcef.so
#12 0x00007fffe5f4f77e in cc::TiledLayer::UpdateTiles(int, int, int, int, cc::ResourceUpdateQueue*, cc::OcclusionTracker<cc::Layer> const*, bool*) () at ./libcef.so
#13 0x00007fffe5f50a0a in cc::TiledLayer::Update(cc::ResourceUpdateQueue*, cc::OcclusionTracker<cc::Layer> const*) () at ./libcef.so
#14 0x00007fffe5fcc1ca in cc::LayerTreeHost::PaintLayerContents(cc::RenderSurfaceLayerList const&, cc::ResourceUpdateQueue*, bool*, bool*) () at ./libcef.so
#15 0x00007fffe5fcb987 in cc::LayerTreeHost::UpdateLayers(cc::Layer*, cc::ResourceUpdateQueue*) () at ./libcef.so
#16 0x00007fffe5fcb510 in cc::LayerTreeHost::UpdateLayers(cc::ResourceUpdateQueue*) () at ./libcef.so
#17 0x00007fffe5fed1e6 in cc::SingleThreadProxy::DoCommit(cc::BeginFrameArgs const&) () at ./libcef.so
#18 0x00007fffe5fee89c in cc::SingleThreadProxy::CompositeImmediately(base::TimeTicks) () at ./libcef.so
#19 0x00007fffe65bc09e in ui::Compositor::Draw() () at ./libcef.so
#20 0x00007fffe47f3302 in base::debug::TaskAnnotator::RunTask(char const*, char const*, base::PendingTask const&) () at ./libcef.so
#21 0x00007fffe481e172 in base::MessageLoop::RunTask(base::PendingTask const&) () at ./libcef.so
#22 0x00007fffe481e6dc in base::MessageLoop::DoWork() () at ./libcef.so
#23 0x00007fffe47e2619 in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) () at ./libcef.so
#24 0x00007fffe4832114 in base::RunLoop::Run() () at ./libcef.so
#25 0x00007fffe471522a in CefBrowserMessageLoop::DoMessageLoopIteration() () at ./libcef.so
#26 0x000000000040a349 in IDLE (WIDGET=0x965040) at minimal.lpr:39
---Type <return> to continue, or q <return> to quit---
#27 0x00007ffff736d8e5 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#28 0x00007ffff736dc48 in () at /usr/lib64/libglib-2.0.so.0
#29 0x00007ffff736dcec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#30 0x00007fffe47e2672 in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) () at ./libcef.so
#31 0x00007fffe4832114 in base::RunLoop::Run() () at ./libcef.so
#32 0x00007fffe481d9ca in base::MessageLoop::Run() () at ./libcef.so
#33 0x000000000040ade3 in main () at minimal.lpr:239

Is this a known bug and what could be the reason? Could this be related to tcmalloc or the change GTK -> Aura?
The only thing I changed compared to the version for 3.1750, is the way CEF is embedded into GTK...

Any help would be greatly appreciated.
Regards

[magreenblatt]

Does the crash occur with the cefclient sample application? If not you might want to compare your application to how that application integrates with GTK.

[dliw]

Yes, both cefclient and cefsimple basically work. The latter randomly crash with a lot of

Code: Select all

[0220/190210:ERROR:gl_context_glx.cc(107)] Couldn't make context current with X drawable.
[0220/190210:ERROR:gles2_cmd_decoder.cc(3055)]   GLES2DecoderImpl: Context lost during MakeCurrent.
[0220/190210:ERROR:gl_bindings_autogen_gl.cc(5194)] Trying to call glGetGraphicsResetStatusARB() without current GL context
[0220/190210:ERROR:gl_bindings_autogen_gl.cc(5194)] Trying to call glGetGraphicsResetStatusARB() without current GL context
[0220/190210:WARNING:x11_util.cc(1464)] X error received: serial 556, error_code 171 (GLXBadDrawable), request_code 155, minor_code 26 (X_GLXMakeContextCurrent)


My code is taken 1:1 from client_gtk.cpp. Actually it's a test app to see what changed.
The only difference is, that I have a gtk main loop running, cef_do_message_loop_work is called periodically from within an idle function.

Would it be of any help if I posted the main code here (~60 lines)? I don't see any relevant differences...
Anyway, thanks so far...

[magreenblatt]

The only difference is, that I have a gtk main loop running, cef_do_message_loop_work is called periodically from within an idle function.

You mentioned in your original post that the same crash occurs when using CefRunMessageLoop() in your application. How does your implementation with CefRunMessageLoop() differ from the cefclient sample application?

[dliw]

I just replaced gtk_main() with cef_run_message_loop(). The behavior remains the same...
Ok, shutdown should be handled differently, but that's not the problem...

Or the other way round:
It is a a simplified version (single button, nothing else) of the int main(int argc, char* argv[]) { function from cefclient_gtk.cpp (Sorry, there was a typo in my previous post - no handler) and replaced CefRunMessageLoop(); with the gtk main loop and an idle function calling cef_do_message_loop_work() periodically.
The _cef_client_t I pass, returns NULL everywhere, so there is no custom handler.

EDIT1:
Did some further testing and implemented a second test as a copy of cefsimple, so no gtk, cef creates it's own window. As soon as the window shows up the crash happens (same backtrace).
Maybe it's even related to this issue...

EDIT2:
For this second test valgrind gives:

Code: Select all

==14503== Invalid free() / delete / delete[] / realloc()
==14503==    at 0x4C2A37C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==14503==    by 0x81EE012: sk_free(void*) (SkMemory_new_handler.cpp:45)
==14503==    by 0x7DF9028: sk_free_releaseproc(void*, void*) (SkMallocPixelRef.cpp:15)
==14503==    by 0x7DF97D2: SkMallocPixelRef::~SkMallocPixelRef() (SkMallocPixelRef.cpp:183)
==14503==    by 0x7DF9838: SkMallocPixelRef::~SkMallocPixelRef() (SkMallocPixelRef.cpp:180)
==14503==    by 0x7948CF6: SkRefCntBase::internal_dispose() const (SkRefCnt.h:111)
==14503==    by 0x74A7109: SkRefCntBase::unref() const (SkRefCnt.h:81)
==14503==    by 0x7D5954C: SkBitmap::freePixels() (SkBitmap.cpp:383)
==14503==    by 0x7D594F1: SkBitmap::~SkBitmap() (SkBitmap.cpp:45)
==14503==    by 0x7D62AE4: SkBitmapDevice::~SkBitmapDevice() (SkBitmapDevice.h:15)
==14503==    by 0x7D62B18: SkBitmapDevice::~SkBitmapDevice() (SkBitmapDevice.h:15)
==14503==    by 0x7948CF6: SkRefCntBase::internal_dispose() const (SkRefCnt.h:111)
==14503==  Address 0x2d2ccbef0020 is not stack'd, malloc'd or (recently) free'd
==14503==
==14503== Source and destination overlap in memcpy(0x2d2ccc227948, 0x2d2ccc227948, 38)
==14503==    at 0x4C2DCAC: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==14503==    by 0x75BD681: base::PendingTask::operator=(base::PendingTask const&) (pending_task.h:20)
==14503==    by 0x75BD4C1: void std::__pop_heap<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<base::PendingTask*, std::__cxx1998::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::less<base::PendingTask> >(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<base::PendingTask*, std::__cxx1998::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> > >, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<base::PendingTask*, std::__cxx1998::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> > >, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<base::PendingTask*, std::__cxx1998::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::less<base::PendingTask>) (stl_heap.h:333)
==14503==    by 0x75BC7D2: void std::pop_heap<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<base::PendingTask*, std::__cxx1998::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::less<base::PendingTask> >(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<base::PendingTask*, std::__cxx1998::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> > >, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<base::PendingTask*, std::__cxx1998::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> > >, std::less<base::PendingTask>) (stl_heap.h:362)
==14503==    by 0x75BBE79: std::priority_queue<base::PendingTask, std::__debug::vector<base::PendingTask, std::allocator<base::PendingTask> >, std::less<base::PendingTask> >::pop() (stl_queue.h:526)
==14503==    by 0x75BA3B7: base::MessageLoop::DoDelayedWork(base::TimeTicks*) (message_loop.cc:597)
==14503==    by 0x74D79FB: base::MessagePumpGlib::HandleDispatch() (message_pump_glib.cc:278)
==14503==    by 0x74D80A0: base::(anonymous namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) (message_pump_glib.cc:109)
==14503==    by 0x123A3A03: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4200.1)
==14503==    by 0x123A3C47: ??? (in /usr/lib64/libglib-2.0.so.0.4200.1)
==14503==    by 0x123A3CEB: g_main_context_iteration (in /usr/lib64/libglib-2.0.so.0.4200.1)
==14503==    by 0x74D7AB4: base::MessagePumpGlib::Run(base::MessagePump::Delegate*) (message_pump_glib.cc:309)


[dliw]

I can reproduce the identical crash + backtrace with a minimal plain C example program.

The problem somehow is to related to the use of dlopen...
Is this a (known) bug or simply an unsupported use case? The last "official" build 3.1750 worked perfectly for me...

To compile & run the example just run "make", you'll need to put the resources and libraries into the "Release" folder.

[dliw]

I now had the chance to test on a different system (my current one is missing some libraries like libgcrypt.so.11 for the older CEF).
3.1750 runs as expected, 3.2171 crashes.

So using the newer CEF with dlopen is broken, I filed a bug here: https://code.google.com/p/chromiumembed ... il?id=1545