Store the callstack of the IPC sender of ViewMsg_New

Store the callstack of the IPC sender of ViewMsg_New.

This is a temporary change to help track down the bug below, where we try to create a second RenderView with the same routing id in the same process.

BUG=464633
Committed: https://crrev.com/e447c71afc25d6c4df01c9ffa97ce50c65c20f58
Cr-Commit-Position: refs/heads/master@{#320791}

[lfg, 2015-03-16 18:19:22]

lfg@chromium.org changed reviewers:
+ nasko@chromium.org

[lfg, 2015-03-16 18:19:23]

Hi Nasko, please take a look.

The idea is to have this running on a single iteration of canary, so we can try
to trace down the bug.

[nasko, 2015-03-16 18:38:26]

Overall looks good, but I have a question for the renderer side code.

https://codereview.chromium.org/1001153002/diff/40001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1001153002/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:690: memcpy(&stack_debug_info,
&debug_info[0], size * sizeof(unsigned long));
memcpy from the memory of a stl container sounds scary to me. Why not just loop
and copy over the addresses, which will be simpler and since this will be
crashing, performance isn't really critical.

Also, why can't we just use debug::Alias() to force values to show up on the
stack? Have you tried that route?

[lfg, 2015-03-16 19:10:08]

On 2015/03/16 18:38:26, nasko wrote:
> Overall looks good, but I have a question for the renderer side code.
> 
>
https://codereview.chromium.org/1001153002/diff/40001/content/renderer/render...
> File content/renderer/render_frame_impl.cc (right):
> 
>
https://codereview.chromium.org/1001153002/diff/40001/content/renderer/render...
> content/renderer/render_frame_impl.cc:690: memcpy(&stack_debug_info,
> &debug_info[0], size * sizeof(unsigned long));
> memcpy from the memory of a stl container sounds scary to me. Why not just
loop
> and copy over the addresses, which will be simpler and since this will be
> crashing, performance isn't really critical.

The C++ spec requires that vectors are stored in a contiguous memory space,
however, I'm not opposed to doing a deep copy here. Changed.

> Also, why can't we just use debug::Alias() to force values to show up on the
> stack? Have you tried that route?

I wasn't aware of that class. But looking at its implementation, it only
guarantees that the value will be stored in memory (i.e. not in a register). In
this particular case, since the vector is already allocated on the heap, it
would be a noop.

[nasko, 2015-03-16 20:37:05]

nasko@chromium.org changed reviewers:
+ creis@chromium.org, dxie@chromium.org

[nasko, 2015-03-16 20:37:06]

Including creis@ and dxie@ for FYI.

LGTM

[lfg, 2015-03-16 20:53:06]

The CQ bit was checked by lfg@chromium.org

[commit-bot: I haz the power, 2015-03-16 20:53:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1001153002/80001

[commit-bot: I haz the power, 2015-03-16 20:57:42]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-03-16 20:58:26]

Patchset 5 (id:??) landed as
https://crrev.com/e447c71afc25d6c4df01c9ffa97ce50c65c20f58
Cr-Commit-Position: refs/heads/master@{#320791}