Crash on using the search box

[Vadim Peretokin]

See http://forums.mudlet.org/viewtopic.php?f=9&t=4598&p=21696#p21693 and http://forums.mudlet.org/viewtopic.php?f=9&t=4598&start=40#p21611 for two reports of this happening.

Just clicking on the search box can cause a crash: http://forums.mudlet.org/viewtopic.php?f=5&t=4695&start=30#p22489

Different stacktraces, just clicking on the search bar does it: https://bugs.launchpad.net/mudlet/+bug/1416757
http://pastebin.com/fTnNqeQD
http://pastebin.com/njWHEEvK
http://pastebin.com/sqMsbVKq
http://pastebin.com/wtSegBRW

Haven't gotten a detailed and a reproducible test case yet, though.

Qt bugreport: https://bugreports.qt.io/browse/QTBUG-44244

[Vadim Peretokin (vperetokin)]

It's still a pretty consistent theme that the search box is crashy:

(from Discord)
no idea how to change the look of mudlet, i also want to remove some of the things i dun want there, like the seach (keep crashing mudlet)

From Achaea forums, crash on 3.0-delta that's seconded by several people:
I'm on 3.0.0-delta. Every now and then when I use the search box function, all of mudlet will crash.

I also have the bug Cooper mentioned where I crash randomly sometimes when I mess with the search bar. I cannot pin down any specific cause.

Also experiencing this.

Also voicing the sometimes crashing on search function in delta. Which is a shame because it is so useful but i avoid it unless im in a 100% okay position to crash.

Tapping the mouse on the interface, usually around the search box on the bottom right. (see OSX crashes)

[Sloth (slothmagi)]

on windows

Here is how to reproduce this bug:
- scroll up in main window, so it will divide main window in two split screens
- then use search field in main windows so it will find something
- then highlight some text in scrolled main widow with mouse = crash.

hope this helps

[Vadim Peretokin (vperetokin)]

I tried it, but it didn't crash for me, see attachment. Did I do it right?
×

On Thu, Mar 2, 2017 at 1:56 PM Sloth <email address hidden> wrote:

> on windows
>
> Here is how to reproduce this bug:
> - scroll up in main window, so it will divide main window in two split
> screens
> - then use search field in main windows so it will find something
> - then highlight some text in scrolled main widow with mouse = crash.
>
> hope this helps
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1374684
>
> Title:
> Crash on using the search box
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1374684/+subscriptions
>

[Chris Leacy (cleacy1972)]

The same (similar) problem exists in iota and release30 in windows. It occurs when the main window is split, and a lot of text is arriving from the mud: It may or may not be related to how much of the new text arriving is also gagged/deleted. The search box itself will occasionally crash, but much more likely to occur and should be easily reproducible is attempting to highlight and copy something at this time (window is split, and a lot of text is arriving)

[Vadim Peretokin (vperetokin)]

Thanks for the additional detail! Sounds like we have 2 types of crashes
then: when you search and when you highlight text in a split screen while a
lot of text is arriving.

On Thu, 2 Mar 2017 4:26 pm Chris Leacy, <email address hidden> wrote:

> The same (similar) problem exists in iota and release30 in windows. It
> occurs when the main window is split, and a lot of text is arriving from
> the mud: It may or may not be related to how much of the new text
> arriving is also gagged/deleted. The search box itself will occasionally
> crash, but much more likely to occur and should be easily reproducible
> is attempting to highlight and copy something at this time (window is
> split, and a lot of text is arriving)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1374684
>
> Title:
> Crash on using the search box
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1374684/+subscriptions
>

[Sloth (slothmagi)]

possible. thanks for fixing

[Stephen Lyons (slysven)]

I still think that the way we process incoming MUD data could be suspect in that (void)cTelnet::handle_socket_signal_readyRead() is a SLOT that is coupled to an asynchronous SIGNAL generated by a separate (Qt provided) network thread that manages (QTcpSocket)cTelnet::socket so we have to be careful to make any class members it modifies be used in a re-entrant or is that thread-safe manner? I.e.:

Looks contentious:
(bool)Host::mInsertedMissingLF
(bool)cTelnet::recvdGA
(bool)cTelnet::iac
(bool)cTelnet::iac2
(bool)cTelnet::insb
(std::string)cTelnet::command

Safe-ish probably only because they are not modified frequently:
(bool)cTelnet::mMCCP_version_1
(bool)cTelnet::mMCCP_version_2
(bool)cTelnet::mFORCE_GA_OFF
(bool)cTelnet::mGA_Driver
(bool)cTelnet::mLF_ON_GA
(bool)cTelnet::mNeedDecompression
(bool)TConsole::mRecordReplay

Probably safe:
(bool)cTelnet::mWaitingForResponse
(QTime)cTelnet::timeOffset
(QTime)cTelnet::networkLatencyTime
(double)cTelnet::networkLatency

Note that "command" in void cTelnet::processTelnetCommand(const string &) is a local variable {the passed argument, NOT the class member of the same name which it masks - tut, tut!}

[Vadim Peretokin (vperetokin)]

All good information, thank you. On my side I'm going to try and setup a
reproducible test case so we can know when we've fixed the bug.

On Sat, Mar 4, 2017 at 8:59 PM Stephen Lyons <email address hidden>
wrote:

> I still think that the way we process incoming MUD data could be suspect
> in that (void)cTelnet::handle_socket_signal_readyRead() is a SLOT that
> is coupled to an asynchronous SIGNAL generated by a separate (Qt
> provided) network thread that manages (QTcpSocket)cTelnet::socket so we
> have to be careful to make any class members it modifies be used in a
> re-entrant or is that thread-safe manner? I.e.:
>
> Looks contentious:
> (bool)Host::mInsertedMissingLF
> (bool)cTelnet::recvdGA
> (bool)cTelnet::iac
> (bool)cTelnet::iac2
> (bool)cTelnet::insb
> (std::string)cTelnet::command
>
> Safe-ish probably only because they are not modified frequently:
> (bool)cTelnet::mMCCP_version_1
> (bool)cTelnet::mMCCP_version_2
> (bool)cTelnet::mFORCE_GA_OFF
> (bool)cTelnet::mGA_Driver
> (bool)cTelnet::mLF_ON_GA
> (bool)cTelnet::mNeedDecompression
> (bool)TConsole::mRecordReplay
>
> Probably safe:
> (bool)cTelnet::mWaitingForResponse
> (QTime)cTelnet::timeOffset
> (QTime)cTelnet::networkLatencyTime
> (double)cTelnet::networkLatency
>
> Note that "command" in void cTelnet::processTelnetCommand(const string
> &) is a local variable {the passed argument, NOT the class member of the
> same name which it masks - tut, tut!}
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1374684
>
> Title:
> Crash on using the search box
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1374684/+subscriptions
>

[Sloth (slothmagi)]

let me know if want me to test it. thanks

[Vadim Peretokin (vperetokin)]

Migrating issues to Github, please follow the new discussion here: https://github.com/Mudlet/Mudlet/issues/497

This issue needs to be closed and there is no appropriate status, so will set it to "Opinion" just for migration purposes.

[Vadim Peretokin (vperetokin)]

Migrating issues to Github, please follow the new discussion here: https://github.com/Mudlet/Mudlet/issues/517

This issue needs to be closed and there is no appropriate status, so will set it to "Opinion" just for migration purposes.