search

DynamoRIO / drmemory

Memory Debugger for Windows, Linux, Mac, and Android
Other
2.43k stars 262 forks source link

Likely unhandled syscall in Chromium cricket::UDPPort::OnReadPacket causes false positive uninits #744

Open derekbruening opened 9 years ago

derekbruening commented 9 years ago

From rnk@google.com on January 12, 2012 12:15:22

I don't have the logs and I haven't attempted to reproduce locally, but I'm assuming this is a system call out write that we're not handling appropriately.

Example report: http://build.chromium.org/p/chromium.fyi/builders/Windows&#37;20Tests&#37;20&#37;28DrMemory&#37;20full&#37;29/builds/332/steps/memory&#37;20test&#37;3A&#37;20remoting/logs/stdio Dr.M Error #2: UNINITIALIZED READ: reading register eflags Dr.M # 0 cricket::StunMessage::Read [third_party\libjingle\source\talk\p2p\base\stun.cc:152] Dr.M # 1 cricket::Port::GetStunMessage [third_party\libjingle\source\talk\p2p\base\port.cc:245] Dr.M # 2 cricket::Port::OnReadPacket [third_party\libjingle\source\talk\p2p\base\port.cc:209] Dr.M # 3 cricket::UDPPort::OnReadPacket [third_party\libjingle\source\talk\p2p\base\udpport.cc:109] Dr.M # 4 sigslot::_connection4<cricket::UDPPort,talk_base::AsyncPacketSocket ,char const ,unsigned int,talk_base::SocketAddress const &,sigslot::single_threaded>::emit [third_party\libjingle\source\talk\base\sigslot.h:1960] Dr.M # 5 sigslot::signal4<talk_base::AsyncPacketSocket ,char const ,unsigned int,talk_base::SocketAddress const &,sigslot::single_threaded>::operator() [third_party\libjingle\source\talk\base\sigslot.h:2511] Dr.M # 6 talk_base::AsyncUDPSocket::OnReadEvent [third_party\libjingle\source\talk\base\asyncudpsocket.cc:127] Dr.M # 7 sigslot::_connection1<talk_base::AsyncUDPSocket,talk_base::AsyncSocket ,sigslot::single_threaded>::emit [third_party\libjingle\source\talk\base\sigslot.h:1819] Dr.M # 8 sigslot::signal1<talk_base::AsyncSocket ,sigslot::single_threaded>::operator() [third_party\libjingle\source\talk\base\sigslot.h:2313] Dr.M # 9 talk_base::SocketDispatcher::OnEvent [third_party\libjingle\source\talk\base\physicalsocketserver.cc:1077] Dr.M #10 talk_base::PhysicalSocketServer::Wait [third_party\libjingle\source\talk\base\physicalsocketserver.cc:1596] Dr.M #11 talk_base::MessageQueue::Get [third_party\libjingle\source\talk\base\messagequeue.cc:242] Dr.M #12 talk_base::Thread::ProcessMessages [third_party\libjingle\source\talk\base\thread.cc:499] Dr.M #13 talk_base::Thread::Run [third_party\libjingle\source\talk\base\thread.cc:361] Dr.M #14 remoting::anonymous namespace'::JingleMessagePump::Run [remoting\jingle_glue\jingle_thread.cc:31] \~~Dr.M~~#15MessageLoop::RunInternal [base\message_loop.cc:417] \~~Dr.M~~#16MessageLoop::RunHandler [base\message_loop.cc:390] \~~Dr.M~~#17` MessageLoop::Run [base\message_loop.cc:300] Dr.M Note: @0:04:31.323 in thread 3380 Dr.M Note: instruction: jz $0x01226282

We should add a label for FalsePos-Syscall or Component-Syscall or something so we can easily find unhandled system call bugs.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=744

derekbruening commented 9 years ago

From bruen...@google.com on January 12, 2012 11:02:58

I added FalsePos-Syscall note that there are quite a few filed false pos that are likely from syscalls