Comment #2 on issue 5555 by [email protected]: UMR in
proxy_script_fetcher_unittest
http://code.google.com/p/chromium/issues/detail?id=5555
Thanks for the suggestion.
However according to the purify error log, the address which triggered the
UMR is 44 bytes into the MessageLoop object (this + 44).
This puts the error at this->delayed_work_queue_.comp, which is the
std::queue's comparator (which should be std::less).
> dt -b net_unittests!MessageLoop
+0x000 __VFN_table : Ptr32
=0070d5a8 MessageLoop::event_descriptions_ :
LinearHistogram::DescriptionPair
=0074c260 MessageLoop::enable_histogrammer_ : Bool
+0x004 type_ :
TYPE_DEFAULT = 0
TYPE_UI = 1
TYPE_IO = 2
+0x008 work_queue_ :
std::queue<MessageLoop::PendingTask,std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
> >
+0x000 c :
std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>
+0x000 _Almap : std::allocator<MessageLoop::PendingTask
*>
+0x001 _Alval : std::allocator<MessageLoop::PendingTask>
=00400000 _EEM_DS : Int4B
+0x004 _Map : Ptr32
+0x008 _Mapsize : Uint4B
+0x00c _Myoff : Uint4B
+0x010 _Mysize : Uint4B
+0x01c delayed_work_queue_ :
std::priority_queue<MessageLoop::PendingTask,std::vector<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>,std::less<MessageLoop::PendingTask> >
+0x000 c :
std::vector<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>
+0x000 _Alval : std::allocator<MessageLoop::PendingTask>
+0x004 _Myfirst : Ptr32
+0x008 _Mylast : Ptr32
+0x00c _Myend : Ptr32
+0x010 comp : std::less<MessageLoop::PendingTask>
+0x030 deferred_non_nestable_work_queue_ :
std::queue<MessageLoop::PendingTask,std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>
>
+0x000 c :
std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>
+0x000 _Almap : std::allocator<MessageLoop::PendingTask
*>
+0x001 _Alval : std::allocator<MessageLoop::PendingTask>
=00400000 _EEM_DS : Int4B
...
[truncated]
Purify reports the error as having occurred on line 381 of message_loop.cc:
while (!delayed_work_queue_.empty()) {
Task* task = delayed_work_queue_.top().task;
delayed_work_queue_.pop(); <---------- line 381
delete task;
}
This is about what we would expect given that read violation was in
delayed_work_queue_.comp.
this + 0x2C --> [where UMR occurred]
this + 0x1C --> this->delayed_work_queue_
this + 0x1C + 0x10 --> this->delayed_work_queue_.comp
Purify doesn't report the actual address that faulted, but after
disassembling pop() is is pretty obvious it would be the 6th instruction:
213 005d2cec 8a4810 mov cl,byte ptr [eax+10h]
(Since not only is this the only byte access, but it also represents a
deref of delayed_work_queue_.comp).
The assembly that got generated for pop is quite retarded:
void pop()
{ // erase highest-priority element
pop_heap(c.begin(), c.end(), comp);
c.pop_back();
}
0:006> uf 005d2ce0
net_unittests!std::priority_queue<MessageLoop::PendingTask,std::vector<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>,std::less<MessageLoop::PendingTask> >::pop
[e:\src\chrome3\src\third_party\platformsdk_vista_6_0\files\vc\include\queue
@ 212]:
212 005d2ce0 55 push ebp
212 005d2ce1 8bec mov ebp,esp
212 005d2ce3 83ec14 sub esp,14h
212 005d2ce6 894dec mov dword ptr [ebp-14h],ecx
213 005d2ce9 8b45ec mov eax,dword ptr [ebp-14h]
213 005d2cec 8a4810 mov cl,byte ptr [eax+10h]
213 005d2cef 51 push ecx
213 005d2cf0 8d55f8 lea edx,[ebp-8]
213 005d2cf3 52 push edx
213 005d2cf4 8b4dec mov ecx,dword ptr [ebp-14h]
213 005d2cf7 e8f4060000 call
net_unittests!std::vector<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>::end
(005d33f0)
213 005d2cfc 8b4804 mov ecx,dword ptr [eax+4]
213 005d2cff 51 push ecx
213 005d2d00 8b10 mov edx,dword ptr [eax]
213 005d2d02 52 push edx
213 005d2d03 8d45f0 lea eax,[ebp-10h]
213 005d2d06 50 push eax
213 005d2d07 8b4dec mov ecx,dword ptr [ebp-14h]
213 005d2d0a e8b1060000 call
net_unittests!std::vector<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>::begin
(005d33c0)
213 005d2d0f 8b4804 mov ecx,dword ptr [eax+4]
213 005d2d12 51 push ecx
213 005d2d13 8b10 mov edx,dword ptr [eax]
213 005d2d15 52 push edx
213 005d2d16 e835250000 call
net_unittests!std::pop_heap<std::_Vector_iterator<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>,std::less<MessageLoop::PendingTask> > (005d5250)
213 005d2d1b 83c414 add esp,14h
214 005d2d1e 8b4dec mov ecx,dword ptr [ebp-14h]
214 005d2d21 e8aa070000 call
net_unittests!std::vector<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>
>::pop_back
(005d34d0)
215 005d2d26 8be5 mov esp,ebp
215 005d2d28 5d pop ebp
215 005d2d29 c3 ret
Looks to be copying comp into the low byte of ECX merely so it can push it
onto the stack as a DWORD, presumably as the third argument to
pop_heap. Turns out this is actually quite pointless, since the
implementation of pop_heap never reads its comp parameter.
This is starting to look like an STL-generated code false-positive. It is
conceivable that the generated code therefore never initializes comp
if it will never truly be read. Will have to dig around in the surrounding
assembly to answer this.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-bugs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/chromium-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---
