1928962 - WARNING: Listener is not retargetable: file netwerk/protocol/http/HttpChannelChild.cpp:3044

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect, P2)

Description

[Julian Seward [:jseward]]

When testing our new wasm compilation pipeline, with a debug build of the
browser, I see

[Child 13263, Main Thread] WARNING: Listener is not retargetable: file netwerk/protocol/http/HttpChannelChild.cpp:3044

printed several times. This comes from HttpChannelChild::RetargetDeliveryTo.

In many cases this is shortly followed by a segfault from an assertion failure
a bit further down the method:

3041  if (!retargetableListener || NS_FAILED(rv)) {
3042    NS_WARNING("Listener is not retargetable"); <----------------- HERE
3043    return NS_ERROR_NO_INTERFACE;
3044  }
3045
3046  rv = retargetableListener->CheckListenerChain();
3047  if (NS_FAILED(rv)) {
3048    NS_WARNING("Subsequent listeners are not retargetable");
3049    return rv;
3050  }
3051
3052  // We allow multiple retargeting. However all such modification must happen
3053  // before we have have received the first OnDataAvailable.
3054  // See Bug 1887783
3055  MOZ_ASSERT(mOnDataAvailableStartTime.IsNull()); <------------ FAILS
3056  {
3057    MutexAutoLock lock(mEventTargetMutex);
3058    RetargetDeliveryToImpl(aNewTarget, lock);
3059  }

The stack trace at the NS_WARNING is attached.

STR: I have no idea if this associated with wasm; I only know that our tests
cause it to fail.

A recent debug build of m-c (from Sun 3 Nov 2024 or later)

Set javascript.options.wasm_caching = false
Set javascript.options.wasm_lazy_tiering = true
(optional) run with MOZ_LOG=wasmPerf:3

https://zal.im/wasm/jetsnack triggers the above warning.

Comment 1

[Julian Seward [:jseward]]

Attachment: Stack trace at the NS_WARNING

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

A pernosco trace would help a lot, if you can get one.

Comment 3

[Julian Seward [:jseward]]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #2)

A pernosco trace would help a lot, if you can get one.

I've never used pernosco. Where can I see documentation on how to
set up / use it?

FWIW the STR in comment 0 reproduce it easily and reliably.

Comment 4

[Sunil Mayya]

Hello Juilan,
Thanks for STR,
we already have a persnosco trace from a similar bug 1919416.
We will let you know if we need further information.

Comment 6

[Sunil Mayya]

Attachment: Bug 1928962 - ignoring retargetting requests after all the data has been dispatched. r=#necko

Comment 7

[Sunil Mayya]

The problem here is that with FetchPreloader the listener call to OnStartRequest/OnDataAvailable/OnStopRequest are not synchronously executed in HttpChannelChild OnStartRequest/OnDataAvailable/OnStopRequest.
Instead they are cached here and replayed after a listener is available here.
In this scenario, we are first retargetting the data for decompression here. Then an attempt is made to re-target the data delivery once we start executing the cached OnStartRequest. This leads to this assertion.

The purspose of this assertion is that we should not deliver data on two different targets. However, due to FetchPreloader and OMT Decompression we could make this less strict. This can be acheived by failing calls to HttpChannelChild::RetargetDeliveryTo after OnStopRequest has been dispatched i.e. we are ensured no more data is going to be delivered. Out solution should be based on this one.

Comment 8

[Sunil Mayya]

This has now been fixed by patch from Randell in Bug 1917901.
In the fix for Bug 1917901 we no longer assert on multiple retargetting but return the error as described in comment 7