Open
Bug 1334383
Opened 5 years ago
Updated 2 months ago
Intermittent application crashed [@ TimerThread::Run]
Categories
(Core :: DOM: Core & HTML, defect, P5)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: intermittent-bug-filer, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: intermittent-failure)
Crash Data
Attachments
(3 files)
1.96 KB,
patch
|
froydnj
:
review-
|
Details | Diff | Splinter Review |
1.84 KB,
patch
|
Details | Diff | Splinter Review | |
1.75 KB,
patch
|
Details | Diff | Splinter Review |
Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=72453936&repo=autoland https://queue.taskcluster.net/v1/task/Ez4rEHX3Q2OzPwUMkwJxJA/runs/0/artifacts/public/logs/live_backing.log
Updated•5 years ago
|
Blocks: ServiceWorkers-tests
Comment 1•5 years ago
|
||
This is crashing on the nsTimer assertion requiring timers to be released on their target thread: https://dxr.mozilla.org/mozilla-central/source/xpcom/threads/TimerThread.cpp#509 We're hitting this because Workers now use an nsIEventTarget that can fail dispatch if the worker has shutdown. The assertion seems to ignore the fact, though, that timers can be canceled. The WorkerPrivate is gone and can't take a dispatch any more, but before it gets to this state it cancels its timers. Presumably the cancel is triggered just after we start the machinery to do this dispatch on TimerThread. It seems like we have a couple different options: 1) Relax the assertion in the case where the timer was canceled. 2) Add more locking so its impossible for a cancel to occur while we are in the middle of trying to dispatch the timer. Nathan, what do you think?
Flags: needinfo?(nfroyd)
![]() |
||
Comment 2•5 years ago
|
||
So the racy sequence is: WorkerThread: Cancel timer TimerThread: Start the process of trying to dispatch the timer WorkerThread: Release the timer reference TimerThread: Try to dispatch timer, but WorkerThread is not accepting new runnables TimerThread: Release the timer reference, and discover we're on the wrong thread or something to that effect, is that correct? I am not in favor of relaxing that assertion, because we don't want things being destroyed on the timer thread in general. But I'm having a hard time seeing what more locking we could add to try to avoid this situation. Can you explain?
Flags: needinfo?(nfroyd)
Comment 3•5 years ago
|
||
(In reply to Nathan Froyd [:froydnj] from comment #2) > WorkerThread: Cancel timer > TimerThread: Start the process of trying to dispatch the timer > WorkerThread: Release the timer reference > TimerThread: Try to dispatch timer, but WorkerThread is not accepting new > runnables > TimerThread: Release the timer reference, and discover we're on the wrong > thread Yes, exactly. Although maybe its more like the first two are swapped: TimerThread: Start the process of trying to dispatch the timer WorkerThread: Cancel timer WorkerThread: Release the timer reference TimerThread: Try to dispatch timer, but WorkerThread is not accepting new runnables TimerThread: Release the timer reference, and discover we're on the wrong thread TimerThread could lock a mutex specific to the timer in step 1. That would make WorkerThread block when it tries to cancel the timer. Right now it seems Cancel() is busted. It should guarantee that either: 1) The timer is canceled and will not be dispatched. 2) The timer was already dispatched and the Cancel is a no-op. Currently it seems its possible to reach a third possibility: 3) The timer is canceled but nsTimerThread still needs to dispatch it.
Flags: needinfo?(nfroyd)
Comment 4•5 years ago
|
||
> 1) The timer is canceled and will not be dispatched.
> 2) The timer was already dispatched and the Cancel is a no-op.
I guess these should really be:
1) The timer is canceled, will not be dispatched, and timer thread has dropped its ref.
2) The timer was already dispatched, dropped its ref, and the Cancel is a no-op.
![]() |
||
Comment 5•5 years ago
|
||
(In reply to Ben Kelly [:bkelly] from comment #3) > (In reply to Nathan Froyd [:froydnj] from comment #2) > > WorkerThread: Cancel timer > > TimerThread: Start the process of trying to dispatch the timer > > WorkerThread: Release the timer reference > > TimerThread: Try to dispatch timer, but WorkerThread is not accepting new > > runnables > > TimerThread: Release the timer reference, and discover we're on the wrong > > thread > > Yes, exactly. Although maybe its more like the first two are swapped: > > TimerThread: Start the process of trying to dispatch the timer > WorkerThread: Cancel timer > WorkerThread: Release the timer reference > TimerThread: Try to dispatch timer, but WorkerThread is not accepting new > runnables > TimerThread: Release the timer reference, and discover we're on the wrong > thread > > TimerThread could lock a mutex specific to the timer in step 1. That would > make WorkerThread block when it tries to cancel the timer. How long do you want that mutex to be locked? Until the target thread accepts the Dispatch() of the timer runnable? Locking around Dispatch() seems to be asking for bad things to happen, though maybe this is safe with the current worker code... > Right now it seems Cancel() is busted. I *think* bug 1328643 addresses this concern. Alternatively, maybe the worker should cancel all its timers *before* it stops accepting events?
Flags: needinfo?(nfroyd)
Comment 6•5 years ago
|
||
(In reply to Nathan Froyd [:froydnj] from comment #5) > Alternatively, maybe the worker should cancel all its timers *before* it > stops accepting events? I believe this is what we do. We cancel our GC timer in the worker Killing state here: https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#4692 And we accept control runnables for dispatch until we are in the Dead state here: https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#2550 Now, we do immediately set the state to Dead after cancelling the timer runnable, but the worker is accepting dispatches up until right after we call Cancel().
Comment 7•5 years ago
|
||
If nsTimerImpl::Cancel() dropped the callback references then perhaps we could just assert that the callbacks refs were released on the target thread instead of asserting where the nsTimerImpl itself is released.
Comment 8•5 years ago
|
||
Actually, we do release the callback in Cancel(): https://dxr.mozilla.org/mozilla-central/source/xpcom/threads/nsTimerImpl.cpp#318 Nathan, what do you think about asserting we are on the target thread here: https://dxr.mozilla.org/mozilla-central/source/xpcom/threads/nsTimerImpl.h#74 And then dropping the assertion in comment 1. I think the really important thing is that the caller's callback objects are released on the target thread. It doesn't matter so much where the nsTimerImpl itself is released.
![]() |
||
Comment 10•5 years ago
|
||
(In reply to Ben Kelly [:bkelly] from comment #8) > Nathan, what do you think about asserting we are on the target thread here: > > https://dxr.mozilla.org/mozilla-central/source/xpcom/threads/nsTimerImpl.h#74 I think this is a fine idea. I am a little skeptical about us consistently calling Cancel on the target thread, though, see bug 1328643. I'm pretty sure a short: 1. grep for SetTarget calls; 2. check for Cancel calls on said objects 3. find inconsistencies between where Cancel should be called and where it is called exercise would be fruitful in finding bugs. > I think the really important thing is that the caller's callback objects are > released on the target thread. It doesn't matter so much where the > nsTimerImpl itself is released. Yes.
Flags: needinfo?(nfroyd)
Comment 11•5 years ago
|
||
Bug 1328643 landed, but we are still getting a few of these crashes: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-inbound&job_id=74922198&lineNumber=15078 https://treeherder.mozilla.org/logviewer.html#?repo=autoland&job_id=75211120&lineNumber=8117 I think we need the fixes I discuss in bug 1325254 comment 45.
Comment 12•5 years ago
|
||
One thing we could try to do is avoid this unlock in TimerThread::PostTimerEvent(): https://dxr.mozilla.org/mozilla-central/source/xpcom/threads/TimerThread.cpp#716 The comments suggest the only reason we unlock around the nsIEventTarget::Dispatch() is to avoid deadlock on self dispatch. We could do a nsIEventTarget::IsOnCurrentThread() and only unlock if it returns true. Nathan, what do you think?
Flags: needinfo?(nfroyd)
Comment 13•5 years ago
|
||
I keep losing this bug and have to search for it, so assigning to myself.
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
![]() |
||
Comment 14•5 years ago
|
||
(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #12) > One thing we could try to do is avoid this unlock in > TimerThread::PostTimerEvent(): > > https://dxr.mozilla.org/mozilla-central/source/xpcom/threads/TimerThread. > cpp#716 > > The comments suggest the only reason we unlock around the > nsIEventTarget::Dispatch() is to avoid deadlock on self dispatch. We could > do a nsIEventTarget::IsOnCurrentThread() and only unlock if it returns true. > > Nathan, what do you think? I know I reviewed the patch that added that comment, but I'm unsure the problem it's describing exists: the timer can't be targeted at the timer thread, because the timer thread object itself is not nsIEventTarget, and even the mThread member isn't really a generally-accessible nsIEventTarget. Even if you were dispatching at the mThread member, the event wouldn't run, because mThread isn't exactly running a normal event loop. So your proposed scheme seems almost safe, except...We might deadlock if something's Dispatch() method attempted to re-enter the TimerThread code by adding or removing timers, which doesn't seem so far-fetched.
Flags: needinfo?(nfroyd)
Comment 15•5 years ago
|
||
(In reply to Nathan Froyd [:froydnj] from comment #14) > So your proposed scheme seems almost safe, except...We might deadlock if > something's Dispatch() method attempted to re-enter the TimerThread code by > adding or removing timers, which doesn't seem so far-fetched. An nsIEventTarget::Dispatch() that tries to use nsITimer again? That seems very strange to me for an event target. Can we just document that code shouldn't do that?
Comment 16•5 years ago
|
||
Also it seems we could make nsITimer::Init() return an error if its called on the timer thread. What do you think?
Flags: needinfo?(nfroyd)
Comment hidden (Intermittent Failures Robot) |
![]() |
||
Comment 18•5 years ago
|
||
(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #16) > Also it seems we could make nsITimer::Init() return an error if its called > on the timer thread. What do you think? I think this is completely reasonable. I am less enthused about trying to restrict what you can do in nsIEventTarget::Dispatch.
Flags: needinfo?(nfroyd)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•5 years ago
|
Crash Signature: [@ TimerThread::Run]
Summary: Intermittent dom/tests/mochitest/fetch/test_fetch_basic_http_sw_empty_reroute.html | application crashed [@ TimerThread::Run] → Intermittent application crashed [@ TimerThread::Run]
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 37•5 years ago
|
||
Byron, this bug (and the numerous dupes floating around out there) are really frequent. Any chance you could take a look?
Flags: needinfo?(docfaraday)
Comment 38•5 years ago
|
||
I know what this is and its on my list. Its been a low priority for me because it didn't look that frequent and I believe its a DEBUG-only thing. I don't think the assertions are actually a problem for release build in this case. I'll try to get to this in FF55 time frame.
Flags: needinfo?(docfaraday)
Comment 39•5 years ago
|
||
I have a patch for this on another bug, let me link.
Comment 42•5 years ago
|
||
(In reply to Byron Campen [:bwc] from comment #41) > Should I go ahead and move the patch over here? So, I talked to Nathan about loosening the assertion if Dispatch() failed there after a cancel. He didn't like it previously. I think we need to extend the lock over the Dispatch() call so that the Worker thread can't die while a timer is trying to dispatch to it. This needs probably some extra flag or something on the timer target that says "lock over this target...". Maybe a QI'able interface on the event target.
Flags: needinfo?(bkelly)
Comment 43•5 years ago
|
||
(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #42) > (In reply to Byron Campen [:bwc] from comment #41) > > Should I go ahead and move the patch over here? > > So, I talked to Nathan about loosening the assertion if Dispatch() failed > there after a cancel. He didn't like it previously. > > I think we need to extend the lock over the Dispatch() call so that the > Worker thread can't die while a timer is trying to dispatch to it. This > needs probably some extra flag or something on the timer target that says > "lock over this target...". Maybe a QI'able interface on the event target. I don't see the value of doing this. If a thread stops accepting runnables while a timer is about to dispatch, so what?
Comment 44•5 years ago
|
||
(In reply to Byron Campen [:bwc] from comment #43) > I don't see the value of doing this. If a thread stops accepting runnables > while a timer is about to dispatch, so what? Well, if Cancel() was not called on the nsITimer then this is a definite bug. Many nsITimer callbacks and closures are not thread safe to release. So we must ensure it gets released on the target thread. For these particular crashes, though, the worker code is calling Cancel(). So I don't think this particular case is a problem for release builds. We can't just relax the assertions, though, or other real problems would no longer be caught.
Comment hidden (Intermittent Failures Robot) |
Comment 46•5 years ago
|
||
I will try to write a patch for this today.
Comment 47•5 years ago
|
||
Comment 48•5 years ago
|
||
Comment 49•5 years ago
|
||
Comment 50•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=993fc274a1438843198cb9105c2f5f1badc071bc
Comment 51•5 years ago
|
||
Comment on attachment 8873028 [details] [diff] [review] P1 Add the nsILockable mix-in interface. r=froydnj Add a mix-in interface that nsIEventTargets can implement to signal that Dispatch() can be called while a lock is held.
Attachment #8873028 -
Flags: review?(nfroyd)
Comment 52•5 years ago
|
||
Comment on attachment 8873029 [details] [diff] [review] P2 Make TimerThread::PostTimerEvent() keep its lock if the event target implements nsILockable. r=froydnj This patch makes TimerThread call Dispatch() with the lock held if the target implements nsILockable.
Attachment #8873029 -
Flags: review?(nfroyd)
Comment 53•5 years ago
|
||
Comment on attachment 8873030 [details] [diff] [review] P3 Make WorkerControlEventTarget implement nsILockable. r=froydnj Make the Worker event target used for timers implement nsILockable. It does not call into nsITimer directly, so deadlock is not possible. I believe this should fix the assertions. If TimerThread starts processing a worker nsITimer it will complete the Dispatch() before Cancel() can be called. If the worker shuts down before the TimerThread gets to the timer, then Cancel() will be called and TimerThread will ignore it.
Attachment #8873030 -
Flags: review?(nfroyd)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
![]() |
||
Comment 71•5 years ago
|
||
Comment on attachment 8873028 [details] [diff] [review] P1 Add the nsILockable mix-in interface. r=froydnj Review of attachment 8873028 [details] [diff] [review]: ----------------------------------------------------------------- This whole intermittent and its solution is just ugly, there's no way around it. But I think a generic nsILockable interface promises too much: safe to invoke all of its methods while holding a lock? That's a pretty tall order, and we'd have to QI just to make sure that we have one of these things, which is relatively expensive. I think the better way forward is to define an infallible noscript method on nsIEventTarget like isWorkerControlThread, which is more targeted and more efficient. It'd be ideal if we could implement this proposed method in just one place, but I don't see a good way for that to work. Ideally the implementation using that method should be obvious; ping me on IRC if it's not.
Attachment #8873028 -
Flags: review?(nfroyd) → review-
![]() |
||
Updated•5 years ago
|
Attachment #8873029 -
Flags: review?(nfroyd)
![]() |
||
Updated•5 years ago
|
Attachment #8873030 -
Flags: review?(nfroyd)
Comment 72•5 years ago
|
||
(In reply to Nathan Froyd [:froydnj] from comment #71) > I think the better way forward is to define an infallible noscript method on > nsIEventTarget like isWorkerControlThread, which is more targeted and more > efficient. It'd be ideal if we could implement this proposed method in just > one place, but I don't see a good way for that to work. Ideally the > implementation using that method should be obvious; ping me on IRC if it's > not. I really disagree about making TimerThread look for something worker specific. This is not worker specific. There is nothing that stops other event targets from entering a shutdown state. For example, this same problem can occur doing: 1. Create some private nsThread for a feature 2. Setup a timer targeting that nsThread 3. Feature calls nsITimer::Cancel() and then shutsdown the thread so nsThread::mEventsAreDoomed is set to true. 4. The nsThread::Dispatch() will start returning failure. The TimerThread either needs to: 1. Lock around Dispatch() to avoid letting the Cancel() through 2. Accept that you might fail to dispatch an nsTimer if its Cancel() method has been called Personally I think (2) would be fine and we could just loosen the assertion to permit canceled nsTimers. I seem to recall you don't like that idea, though. Can you suggest something you would accept that is not Worker specific?
Flags: needinfo?(nfroyd)
Comment 73•5 years ago
|
||
I would also be happy to rename my nsILockable interface to nsIDispatchLockableByTimerThread or something else specific.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 80•5 years ago
|
||
Moving this over to Nathan as the xpcom owner. I'm happy to help here, but I think he needs to determine which was he wants this to go first. Just didn't want to leave myself assigned since I'm not actively working it at the moment.
Assignee: bkelly → nfroyd
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•4 years ago
|
Priority: -- → P5
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Updated•3 years ago
|
Component: DOM → DOM: Core & HTML
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•3 years ago
|
Crash Signature: [@ TimerThread::Run] → [@ TimerThread::Run]
[@ TimerThread::Run()]
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
![]() |
||
Updated•3 years ago
|
Crash Signature: [@ TimerThread::Run]
[@ TimerThread::Run()] → [@ TimerThread::Run]
[@ TimerThread::Run()]
Flags: needinfo?(nfroyd)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 235•2 months ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: froydnj+bz → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(htsai)
Updated•2 months ago
|
Flags: needinfo?(htsai)
You need to log in
before you can comment on or make changes to this bug.
Description
•