Updates:
Cc: [email protected]
Comment #3 on issue 5555 by [email protected]: UMR in
proxy_script_fetcher_unittest
http://code.google.com/p/chromium/issues/detail?id=5555
Sorry for the long-winded conclusion:
This looks to be a false-positive based on how VS compiles the STL code for
std::priority_queue.
The priority_queue stores a "comparator", which is an argument to the
template. In our case it is the default
std::less. std::less is a functor which has no data members -- only a
parenthesis operator.
So conceptually, std::less occupies 0 space, and the |comp| field is
0-sized. In practice however, VS will
reserve space for it anyway. It reserves 1 byte for the field, and pads
with another 3 bytes (presumably to keep
the structure DWORD aligned).
So far so good.
The problem happens now when code tries to read the value of |comp|, as it
truly is un-initialized. The compiled
code's logic is sound, and no-one actually depends on the value of |comp|.
However, the code generated for
"pop()" is pretty lame and pushes |comp| onto the stack to pass it as a
parameter for "pop_heap()". "pop_heap()"
doesn't actually use the argument, so this was pointless. However the act
of copying it onto the stack does
represent a real UMR (but a benign one).
I tickle this codepath in ProxyScriptFetcher's unit-tests, because delayed
tasks are left in the work-queue to be
cleaned up on thread destruction. This is expected, and by design: each
time the ProxyScriptFetcher initiates a
URLRequest, it posts a delayed task. This delayed task's purpose is to
abort the request should it take too long
(so it's delay is the timeout). This does mean that while destroying
MessageLoop we will reach the problematic
delayed_work_queue_.pop() line, and trigger the UMR.
while (!delayed_work_queue_.empty()) {
Task* task = delayed_work_queue_.top().task;
delayed_work_queue_.pop();
delete task;
}
So the question now is: why does purify only complain about
ProxyScriptFetcherTest*, shouldn't this happen
elsewhere too?
Well, for starters, ProxyScriptFetcherTest* is the only test in
net_unittests.exe which leaves delayed tasks in
the work queue upon completion and thereby hits this codepath. I verified
this by adding a
CHECK(delayed_work_queue_.empty()) and re-running net_unittests.exe -- none
of the other tests hit it.
The problem with my logic however, is that base_unittests.exe DOES hit this
same codepath.
And yet apparently base_unittests.exe does not trip up Purify. I don't have
a good explanation for this, other
than to suggest that Purify may be fragile in how it detects this error.
The fact that I cannot repro locally,
but it does repro on the buildbot might be a symptom of such fragility.
(alternatively perhaps there is a filter already setup that I am not
seeing).
erikkay, does this sound reasonable to you?
can we just ignore this case?
--
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
-~----------~----~----~----~------~----~------~--~---
