Steps to reproduce the problem:
I'm a browser developer.
Recently, we have collected many crashes while calling glBindFramebufferEXT, the crash call stack is:

Thread Name: 'Chrome_InProcGp'
pid: 12794, tid: 13042  >>> com.UCMobile <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr c1b010f8
  r0 a1b010f4  r1 f1e3bd74  r2 80000000  r3 07ffffff
  r4 80000262  r5 ffffffff  r6 00000262  r7 00000000
  r8 00000000  r9 00000002  10 f1901114  fp fffffff8
  ip 0000001f  sp b687f204  lr c1b010f0  pc f1dfe9ba  cpsr 20000030
    #00 pc 000539ba arena_run_reg_alloc LINE:libc.so
    #01 pc 00053851 je_arena_tcache_fill_small LINE:libc.so
    #02 pc 0006e3dd je_tcache_alloc_small_hard LINE:libc.so
    #03 pc 0006441d je_calloc LINE:libc.so
    #04 pc 00173521 EsxLinkedList::GetNewEntry() LINE:libGLESv2_adreno.so
    #05 pc 0015d98b EsxCmdBuf::GetMemoryFromPool(int) LINE:libGLESv2_adreno.so
    #06 pc 0015d8bd EsxCmdBuf::CreateMemPool(EsxCmdBufCreateData const*) LINE:libGLESv2_adreno.so
    #07 pc 0015d7bb EsxCmdBuf::Create(EsxCmdBufCreateData*) LINE:libGLESv2_adreno.so
    #08 pc 000c9ae5 EsxFramebufferObject::Init(EsxFramebufferObjectCreateData*) LINE:libGLESv2_adreno.so
    #09 pc 00089b47 EsxContext::GlBindFramebuffer(unsigned int, unsigned int) LINE:libGLESv2_adreno.so
    #10 pc 00cbf3d1 gpu::gles2::GLES2DecoderImpl::DoBindFramebuffer(unsigned int, unsigned int) LINE: gles2_cmd_decoder.cc:5703
    #11 pc 00cbf50d gpu::gles2::GLES2DecoderImpl::HandleBindFramebuffer(unsigned int, void const volatile*) LINE: gles2_cmd_decoder_autogen.h:103
    #12 pc 00cd8b4d gpu::error::Error gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<false>(unsigned int, void const volatile*, int, int*) LINE: gles2_cmd_decoder.cc:5222
    #13 pc 00ca2d8d gpu::CommandParser::ProcessCommands(int) LINE: cmd_parser.cc:54
    #14 pc 00ca3441 gpu::CommandExecutor::PutChanged() LINE: command_executor.cc:61
    #15 pc 00d67611 gpu::GpuCommandBufferStub::OnAsyncFlush(int, unsigned int, std::__ndk1::vector<ui::LatencyInfo, std::__ndk1::allocator<ui::LatencyInfo> > const&) LINE: gpu_command_buffer_stub.cc:886
    #16 pc 00d67eb5 gpu::GpuCommandBufferStub::OnMessageReceived(IPC::Message const&) LINE: gpu_command_buffer_stub.cc:298
    #17 pc 00d66631 gpu::GpuChannel::HandleMessageHelper(IPC::Message const&) LINE: gpu_channel.cc:806
    #18 pc 00d6668d gpu::GpuChannel::HandleMessage(scoped_refptr<gpu::GpuChannelMessageQueue> const&) LINE: gpu_channel.cc:786
    #19 pc 00244a3d base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) LINE: task_annotator.cc:52
    #20 pc 00254dfb base::MessageLoop::RunTask(base::PendingTask*) LINE: message_loop.cc:430
    #21 pc 00255385 base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) LINE: message_loop.cc:439
    #22 pc 002555ff base::MessageLoop::DoWork() LINE: message_loop.cc:532
    #23 pc 002562f9 base::MessagePumpDefault::Run(base::MessagePump::Delegate*) LINE: message_pump_default.cc:33
    #24 pc 00254bff base::MessageLoop::RunHandler() LINE: message_loop.cc:395
    #25 pc 0026464d base::RunLoop::Run() LINE: run_loop.cc:37
    #26 pc 0027a695 base::Thread::ThreadMain() LINE: thread.cc:387
    #27 pc 0027727b ThreadFunc LINE: platform_thread_posix.cc:71
    #28 pc 00046d93 __pthread_start(void*) LINE:libc.so
    #29 pc 00019afd __start_thread LINE:libc.so

Obviously, there is a heap corruption in libGLESv2_adreno.so

The function gpu::gles2::GLES2DecoderImpl::DoBindFramebuffer(gles2_cmd_decoder.cc:5703) is calling GL API glBindFramebufferEXT.

The disassembly of pc (f1dfe9ba, libc.so+000539ba, arena_run_reg_alloc) is:

f1dfe978:	d013      	beq.n	0xf1dfe9a2
f1dfe97a:	eb01 0283 	add.w	r2, r1, r3, lsl #2
f1dfe97e:	3b01      	subs	r3, #1
f1dfe980:	6952      	ldr	r2, [r2, #20]
f1dfe982:	442a      	add	r2, r5
f1dfe984:	eb00 0282 	add.w	r2, r0, r2, lsl #2
f1dfe988:	6892      	ldr	r2, [r2, #8]
f1dfe98a:	fa92 f4a2 	rbit	r4, r2
f1dfe98e:	2a00      	cmp	r2, #0
f1dfe990:	fab4 f484 	clz	r4, r4
f1dfe994:	bf08      	it	eq
f1dfe996:	f04f 34ff 	moveq.w	r4, #4294967295	; 0xffffffff
f1dfe99a:	2b01      	cmp	r3, #1
f1dfe99c:	eb04 1545 	add.w	r5, r4, r5, lsl #5
f1dfe9a0:	d1eb      	bne.n	0xf1dfe97a
f1dfe9a2:	096b      	lsrs	r3, r5, #5
f1dfe9a4:	f005 0c1f 	and.w	ip, r5, #31
f1dfe9a8:	eb00 0e83 	add.w	lr, r0, r3, lsl #2
f1dfe9ac:	2201      	movs	r2, #1
f1dfe9ae:	fa02 f20c 	lsl.w	r2, r2, ip
f1dfe9b2:	f8de 6008 	ldr.w	r6, [lr, #8]
f1dfe9b6:	ea82 0406 	eor.w	r4, r2, r6
f1dfe9ba:	f8ce 4008 	str.w	r4, [lr, #8]   ; <<<<<<<<<<<<< crash at here
f1dfe9be:	4296      	cmp	r6, r2
f1dfe9c0:	d11f      	bne.n	0xf1dfea02
f1dfe9c2:	698a      	ldr	r2, [r1, #24]
f1dfe9c4:	2a01      	cmp	r2, #1
f1dfe9c6:	d91c      	bls.n	0xf1dfea02
f1dfe9c8:	f04f 0e08 	mov.w	lr, #8
f1dfe9cc:	f04f 0c01 	mov.w	ip, #1
f1dfe9d0:	f851 202e 	ldr.w	r2, [r1, lr, lsl #2]
f1dfe9d4:	f003 061f 	and.w	r6, r3, #31
f1dfe9d8:	eb02 1253 	add.w	r2, r2, r3, lsr #5
f1dfe9dc:	fa0c f606 	lsl.w	r6, ip, r6
f1dfe9e0:	eb00 0282 	add.w	r2, r0, r2, lsl #2
f1dfe9e4:	6894      	ldr	r4, [r2, #8]
f1dfe9e6:	ea84 0706 	eor.w	r7, r4, r6
f1dfe9ea:	6097      	str	r7, [r2, #8]
f1dfe9ec:	42b4      	cmp	r4, r6
f1dfe9ee:	d108      	bne.n	0xf1dfea02

lr is point to some impossible mmap, current log is point to:
c01e3000-c1b31000 r-xp 00000000 fd:01 500616   /data/data/com.UCMobile/lib/libwebviewuc.so

And we found that, the memory point by r0 is always '00000014 00000002 00000000' in all crash logs.

We use a heap memory double free test code:

for (int i = 0; i < 1000; ++i) {
    __android_log_print(ANDROID_LOG_INFO, "ss", "test loop: %d", i);
    void* ptr = malloc(524);  // the alloc size must in region [513, 640]
    free(ptr);
    free(ptr);  // double free here
}

It can reproduce the crash stack in libc which like:
    #00 pc 000539ba  /system/lib/libc.so (arena_run_reg_alloc+109)
    #01 pc 00053851  /system/lib/libc.so (je_arena_tcache_fill_small+176)
    #02 pc 0006e3dd  /system/lib/libc.so (je_tcache_alloc_small_hard+16)
    #03 pc 0006441d  /system/lib/libc.so (je_calloc+832)
and the memory pointed by r0 matches '00000014 00000002 00000000' also.

So, we guess there is a double free in libGLESv2_adreno.so, and the double freed memory size is between [513, 640] bytes.

And we confirmed there is a 524 bytes allocation in EsxLinkedList::GetNewEntry() according disassembly, so we guess there maybe an Entry in EsxLinkedList has been double freed.

Our browser is running chromium with single process architecture, thus the android's RenderThread and chromium's Chrome_InProcGp are running in the same process. 
Maybe libGLESv2_adreno.so has not fully considered synchronous locks for all GL APIs, and leads an Entry double-freed in libGLESv2_adreno.so

Is this possible to be resolved?

What is the expected behavior?

What went wrong?
An Entry in EsxLinkedList has been double freed, and leads crash with heap corruption.

Crashed report ID: 

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? N/A 

Chrome version: 61.0.3163.79  Channel: stable
OS Version: 
Flash Version:
 

Deleted: crash.log 101 KB

crash.log 101 KB View Download