Some more updates in my investigation:
Hello!
I ran an "info threads" command, and this is what it came up with:
- Code: Select all
Id Target Id Frame
21 Thread 0x7fffb3fff700 (LWP 29797) "VC manager" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
20 Thread 0x7fffc1069700 (LWP 29796) "Chrome_ChildIOT" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39
[color=#40BF00] 19 Thread 0x7fffc186a700 (LWP 29795) "Chrome_InProcRe" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
[/color] 18 Thread 0x7fffc27fc700 (LWP 29794) "BrowserBlocking" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
17 Thread 0x7fffc2ffd700 (LWP 29792) "MediaStreamDevi" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
16 Thread 0x7fffc37fe700 (LWP 29791) "Chrome_IOThread" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
15 Thread 0x7fffc3fff700 (LWP 29790) "Chrome_CacheThr" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39
14 Thread 0x7fffd0b66700 (LWP 29789) "Chrome_ProcessL" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
13 Thread 0x7fffd1367700 (LWP 29788) "Chrome_FileUser" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
12 Thread 0x7fffd1b68700 (LWP 29787) "Chrome_FileThre" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39
11 Thread 0x7fffd2369700 (LWP 29786) "Chrome_DBThread" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
10 Thread 0x7fffd2b6a700 (LWP 29785) "AudioThread" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
9 Thread 0x7fffe0038700 (LWP 29784) "WorkerPool/2978" pthread_cond_timedwait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:215
8 Thread 0x7fffe2f7b700 (LWP 29783) "WorkerPool/2978" pthread_cond_timedwait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:215
7 Thread 0x7fffd336b700 (LWP 29782) "inotify_reader" 0x00007ffff76cb023 in select () at ../sysdeps/unix/syscall-template.S:82
6 Thread 0x7fffd3b6c700 (LWP 29780) "NetworkChangeNo" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39
5 Thread 0x7fffe1ad5700 (LWP 29777) "gdbus" 0x00007ffff76c6303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>,
timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
4 Thread 0x7fffe22d6700 (LWP 29776) "dconf worker" 0x00007ffff76c6303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>,
timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
3 Thread 0x7fffe36e5700 (LWP 29774) "embed.out" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
2 Thread 0x7ffff7ff7700 (LWP 29770) "embed.out" 0x00007ffff76cb023 in select () at ../sysdeps/unix/syscall-template.S:82
* 1 Thread 0x7ffff7fd1700 (LWP 29769) "embed.out" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
I've highlighted the specific thread of interest, Thread 19. Switching to that thread and checking the backtrace, gives me this:
- Code: Select all
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1 0x00007fffeed2d3cf in base::ConditionVariable::Wait (this=0x7fffc18692a8) at base/synchronization/condition_variable_posix.cc:37
#2 0x00007fffeed2e9eb in base::WaitableEvent::WaitMany (raw_waitables=0x7fffc1869320, count=2) at base/synchronization/waitable_event_posix.cc:273
#3 0x00007fffeed9a85e in IPC::SyncChannel::WaitForReply (context=0x7fffe38171c0, pump_messages_event=0x0) at ipc/ipc_sync_channel.cc:495
#4 0x00007fffeed9a7a5 in IPC::SyncChannel::SendWithTimeout (this=0x7fffe381e100, message=0x7fffe384bb60, timeout_ms=-1)
at ipc/ipc_sync_channel.cc:479
#5 0x00007fffeed9a384 in IPC::SyncChannel::Send (this=0x7fffe381e100, message=0x7fffe384bb60) at ipc/ipc_sync_channel.cc:430
#6 0x00007fffee93fbee in content::ChildThread::Send (this=0x7fffe3823808, msg=0x7fffe384bb60) at content/common/child_thread.cc:169
#7 0x00007fffeebd28c8 in content::RenderThreadImpl::Send (this=0x7fffe3823800, msg=0x7fffe384bb60) at content/renderer/render_thread_impl.cc:441
#8 0x00007fffef9a49fd in CefContentRendererClient::RenderThreadStarted (this=0x7fffe3818e70) at cef/libcef/renderer/content_renderer_client.cc:188
#9 0x00007fffeebd2053 in content::RenderThreadImpl::Init (this=0x7fffe3823800) at content/renderer/render_thread_impl.cc:318
#10 0x00007fffeebd1c8c in content::RenderThreadImpl::RenderThreadImpl (this=0x7fffe3823800, channel_name=...)
at content/renderer/render_thread_impl.cc:258
#11 0x00007fffee8135ac in content::RendererMainThread::Init (this=0x7fffe3859be0) at content/browser/renderer_host/render_process_host_impl.cc:151
#12 0x00007fffeed4b6f2 in base::Thread::ThreadMain (this=0x7fffe3859be0) at base/threading/thread.cc:188
#13 0x00007fffeed40a93 in base::(anonymous namespace)::ThreadFunc (params=0x7fffe3850540) at base/threading/platform_thread_posix.cc:65
#14 0x00007ffff73c8e9a in start_thread (arg=0x7fffc186a700) at pthread_create.c:308
#15 0x00007ffff76d1cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#16 0x0000000000000000 in ?? ()
it seems that the Renderer thread itself is waiting for something itself. Specifically, I dug into the code of frame 8 (highlighted in the backtrace above). The blocking line is:
- Code: Select all
thread->Send(new CefProcessHostMsg_GetNewRenderThreadInfo(¶ms));
Internally, it is doing an IPC call, ultimately ending up src/ipc/ipc_sync_channel.cc:471
- Code: Select all
context->ipc_task_runner()->PostDelayedTask(
FROM_HERE,
base::Bind(&SyncContext::OnSendTimeout, context.get(), message_id),
base::TimeDelta::FromMilliseconds(timeout_ms));
After this, it waits for the response, which never arrives. I took a peek at the message object that is being created. It looks like this:
- Code: Select all
{<Pickle> = {_vptr.Pickle = 0x7ffff52ba390, static kPayloadUnit = 64, header_ = 0x7fffb8000cb0, header_size_ = 20, capacity_ = 64,
variable_buffer_offset_ = 0}, file_descriptor_set_ = {ptr_ = 0x0}, received_time_ = 0, output_params_ = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffe7d254d8 ""}},
log_data_ = 0x0, dont_log_ = false}
Here is the message from the client which *does* work:
- Code: Select all
{<Pickle> = {_vptr.Pickle = 0x7ffff7ad7390, static kPayloadUnit = 64, header_ = 0x7fffdad16370, header_size_ = 20, capacity_ = 64,
variable_buffer_offset_ = 0}, file_descriptor_set_ = {ptr_ = 0x0}, received_time_ = 0, output_params_ = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffee8974d8 ""}},
log_data_ = 0x0, dont_log_ = false}
There's no difference between the two messages, so I'm forced to conclude that the problem is not in the message, but rather in the routing:
Based on the IPC configuration on the working CEF client, which I reproduce below, the above IPC call should hit the OnGetNewRenderThreadInfo() method, which it does. But not when run from my code.
- Code: Select all
bool CefBrowserMessageFilter::OnMessageReceived(const IPC::Message& message) {
bool handled = true;
IPC_BEGIN_MESSAGE_MAP(CefBrowserMessageFilter, message)
IPC_MESSAGE_HANDLER(CefProcessHostMsg_GetNewRenderThreadInfo,
OnGetNewRenderThreadInfo)
IPC_MESSAGE_HANDLER(CefProcessHostMsg_GetNewBrowserInfo,
OnGetNewBrowserInfo)
IPC_MESSAGE_UNHANDLED(handled = false)
IPC_END_MESSAGE_MAP()
return handled;
}
What should I check to verify that the IPC call is being routed correctly?
Thanks in advance!