Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/0b02ff/Mudlet-4.3.0-testing-PR3241-868f844-linux-x64.AppImage.tar
• osx: https://make.mudlet.org/snapshots/dba1ab/Mudlet-4.3.0-testing-PR3241-868f844.dmg
• windows: https://make.mudlet.org/snapshots/7e7db3/Mudlet-4.3.0-testing-PR3241-868f8441-windows.zip

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

no crashing on selecting text, but also no text was selected just a bunch of newlines (mac os). In my terminal i see this:

TTextEdit::getSelectedText(...) INFO - unexpectedly hit bottom of method so returning: "\n\n\n\n\n\n\n\n\n\n\n"

that happens anytime i select anything, with various amounts of \n that seems related to how much i selected

Oh, I wasn't smart with what I did. I chose to break out of the loop upon detecting a crash condition rather than continue. Thank you for pointing this out. Each time it did this \n it would have originally crashed. :(

Never mind my previous statement. I used the wrong sign to check the bounds condition, so it always broke the loop when the variable was within the bounds.
I tested by trying to copy text, but I never tried to paste the text. :(
I have now tested copying and pasting the text. It works now.

I had to stare at the code a long time to figure out what the sign should be. I'm getting confused in my old age.

@CriusMacOldenly so you think the issue was with blank lines in the selection?

I think the issue was I used the wrong sign when trying to check for out of bounds. As a result, the code thought in bounds checks were out of bounds fails, and thus didn't actually run the code needed to copy the text.
I also altered the code a bit so if an out of bounds does happen, it will return the text immediately.
I tested copy and paste just enough to show it actually works if done on one pane with ctrl and normal select.
This seems to fix the blank lines in selection.

This undoes all my suggested changes. The only way I can see the crash bug happening the way I tried to fix it, is if mudlet is running multithreaded, and mpBuffer can change while the code is within the function... which is crazy talk, I think.

If this change doesn't work, we have problems. :(

... is if mudlet is running multithreaded, and mpBuffer can change while the code is within the function...

ℹ️ Technically, Mudlet does run multi-threadedly - (for instance, the Qt networking library code runs in a separate thread) - however the Mudlet part of it is effectively a single thread and the things that can modify the TBuffer class (e.g. network data received from the MUD Game server) do so via slot methods (e.g. (void) cTelnet::handle_socket_signal_readyRead()) which are run in that thread!

TBH I am not sure we have drilled down to the cause of the selection crash that you are investigating.

I would note that there can be empty lines in the (QStringList) TBuffer::lineBuffer which means that for some values of y in mpBuffer->lineBuffer.at(y).size() the value returned will be 0 (mpBuffer->lineBuffer.at(y).isEmpty() will return true) and on those lines mpBuffer->lineBuffer.at(y).at(x) will seg. fault for any value of x. Similarly for the corner case of an empty TBuffer - e.g. for a newly created TConsole of any mType a call to mpBuffer->lineBuffer.size() will return zero and any use of mpBuffer->lineBuffer.at(y) will seg. fault...

(std::deque<std::deque<TChar>>) TBuffer::buffer is almost the same - however on empty lines - where there is no TBuffer::lineBuffer content there may well be a default constructed TChar present which gets inserted in this code in TBuffer::translateToPlainText(...):

            // Start a new, but empty line in the various buffers
            ++localBufferPosition;
            std::deque<TChar> newLine;
            buffer.push_back(newLine);
            lineBuffer.push_back(QString());
            timeBuffer.push_back(QString());
            promptBuffer << false;
            dirty << true;

so that calls to mpBuffer->buffer[y].empty() {TBuffer::buffer is an STL data container} ON AN EMPTY LINE will be false but calls to the corresponding mpBuffer->lineBuffer.at(y).isEmpty() {TBuffer::lineBuffer is an Qt data container so has some slight differences in accessor methods compared to STL ones} will return true! 😮

We have not drilled down to the cause of the crashes. I was instructed to fix the crashes with little knowledge of why the crashes were happening, and no way to reliably duplicate the crash.

The best I can do is the try catch method I am suggesting, and I hope someone can send back the variable dump I've put in -- this'll at least explain why the crash is happening. Once I know why the crash is happening, I can better look at how to fix the crash.

It looks like the MacOS builds failed. I don't know why though. :(

Yeah - I'm getting the same error on a PR I have outstanding - seems (AFAICT) like we are trying to install a package (PCRE) which is already in the system - for this to cause a moan and error out instead of letting it through with a "package is already installed" warning I am guessing that we are trying to downgrade this - which is a bit odd... 😜

Maybe. I guess the homebrew environment changed, and what we had before was a pinned pcre version - because upgrading it took way too long due to all the dependencies. So the fix now is to pin to the current version that's already provided.

Maybe. I guess the homebrew environment changed, and what we had before was a pinned pcre version - because upgrading it took way too long due to all the dependencies. So the fix now is to pin to the current version that's already provided.

Nope - it was a too simplistic shell script that was matching an updated brew for pcre2 when we were checking a list for one matching pcre - I have the fix for this pending @vadi2 or @keneanung 's approval as some additional commits (which I will "squash and merge") in #3249 ...

Okay have caused the macOs CI builds to rerun and they have passed now that development has been updated...

Crash condition described in #3239 (comment) which is caused by starting text selection on an empty line has now been fixed.

Great - could you take out all the debugging code? Then we can out it into the release.

Great - could you take out all the debugging code? Then we can out it into the release.

As per your request, the debugging code has been removed. I really hope all the crash bugs are fixed.