Bug 1783504 Comment 34 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Trying to capture a thought we had when talking Artur and I:

The crashes we see (again) have `HandleSameDocumentNavigation` on their stack by chance, as there seem to be an expensive synchronous execution. In fact, `SendDocumentURI` is asynchronous and we cannot be 100% sure that the `RecvDocumentURI` that caused the dump corresponds to the `SendDocumentIRI` inside this `HandleSameDocumentNavigation` call - it might just have been an earlier invocation of `SendDocumentURI` that might have come from different code paths. There is a time window between sending the IPC message on the child side, elaborating it on the parent side and then requesting a dump from the client that could be arbitrarily long, such that we end up scheduling a second `SendDocumentURI` in the meantime. It might be worth looking out for any `SetDocumentURI invocation, especially if coming from Java code.
Trying to capture a thought we had when talking Artur and I:

The crashes we see (again) have `HandleSameDocumentNavigation` on their stack by chance, as there seem to be an expensive synchronous execution. In fact, `SendDocumentURI` is asynchronous and we cannot be 100% sure that the `RecvDocumentURI` that caused the dump corresponds to the `SendDocumentURI` inside this `HandleSameDocumentNavigation` call - it might just have been an earlier invocation of `SendDocumentURI` that might have come from different code paths. There is a time window between sending the IPC message on the child side, elaborating it on the parent side and then requesting a dump from the client that could be arbitrarily long, such that we end up scheduling a second `SendDocumentURI` in the meantime. It might be worth looking out for any `SetDocumentURI invocation, especially if coming from Java code.
Trying to capture a thought we had when talking Artur and I:

The crashes we see (again) have `HandleSameDocumentNavigation` on their stack by chance, as there seem to be an expensive synchronous execution. In fact, `SendDocumentURI` is asynchronous and we cannot be 100% sure that the `RecvDocumentURI` that caused the dump corresponds to the `SendDocumentURI` inside this `HandleSameDocumentNavigation` call - it might just have been an earlier invocation of `SendDocumentURI` that might have come from different code paths. There is a time window between sending the IPC message on the child side, elaborating it on the parent side and then requesting a dump from the client that could be arbitrarily long, such that we end up scheduling a second `SendDocumentURI` in the meantime. It might be worth looking out for any `SetDocumentURI` invocation, especially if coming from Java code.
Trying to capture a thought we had when talking Artur and I:

The crashes we see (again) have `HandleSameDocumentNavigation` on their stack by chance, as there seem to be an expensive synchronous execution. In fact, `SendDocumentURI` is asynchronous and we cannot be 100% sure that the `RecvDocumentURI` that caused the dump corresponds to the `SendDocumentURI` inside this `HandleSameDocumentNavigation` call - it might just have been an earlier invocation of `SendDocumentURI` that might have come from different code paths. There is a time window between sending the IPC message on the child side, elaborating it on the parent side and then requesting a dump from the client that could be arbitrarily long, such that we end up scheduling a second `SendDocumentURI` in the meantime. It might be worth looking out for any `SetDocumentURI` invocation on the child side, especially if coming from Java code.

Back to Bug 1783504 Comment 34