You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the lazy destructors, NetworkAccessManager may get actually fully destructed
before MusixmatchLyricsProvider will be (through LyricsProviders).
But if MusixmatchLyricsProvider had just sent an lyrics request,
and did not get a reply yet, it will have a QNetworkReply* in replies_,
and when NetworkAccessManager destructs, the object, to which that pointer points to,
is also destructed. And once ~MusixmatchLyricsProvider() runs later,
it tries to operate on freed memory...
Locally, this very consistently (100% of the strawberry runs) results in a crash.
I've looked at this, and i don't quite understand how this is supposed to be resolved.
The text was updated successfully, but these errors were encountered:
LebedevRI
added a commit
to LebedevRI/strawberry
that referenced
this issue
Jul 18, 2023
This must be done before the network manager is deleted.
Due to the lazy destruction during `Lazy<>.reset()`,
this appears to be one of the approaches that solves that.
Fixesstrawberrymusicplayer#1239
Due to the lazy destructors,
NetworkAccessManager
may get actually fully destructedbefore
MusixmatchLyricsProvider
will be (throughLyricsProviders
).But if
MusixmatchLyricsProvider
had just sent an lyrics request,and did not get a reply yet, it will have a
QNetworkReply*
inreplies_
,and when
NetworkAccessManager
destructs, the object, to which that pointer points to,is also destructed. And once
~MusixmatchLyricsProvider()
runs later,it tries to operate on freed memory...
Locally, this very consistently (100% of the strawberry runs) results in a crash.
I've looked at this, and i don't quite understand how this is supposed to be resolved.
The text was updated successfully, but these errors were encountered: