Created attachment 146907 [details]
Screen shot of the text area, after restarting Writer

And here's a screen grab of what that area of the document should look like.
Note in the broken render that the visible paragraph marker on the damaged line is displayed on the far right, not where the paragraph really ends.

It may also be worth noting that the line with the broken render had not been edited.

Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.

Maybe related:
bug 109244
bug 117155

Created attachment 146908 [details]
Obfuscating doc but regexp performance is now abysmal

I suspect this will be a hard to reproduce bug. It looks to me like data corruption in the structure used to hold runs of text.  I'll prepare the document anyway.

I'm preparing an obfuscated version of the document at the moment, by running a Find & Replace over the text by doing a Replace All (matching case)
of [bcdfghjklmnpqrstuvwz] by x

F&R with this simple regexp is unacceptably slow.  It's been running for over 30 mins using 100% CPU.  After about 15mins it asked if I would turn off Undo so it could proceed.  I said Yes.

I'll leave it running overnight.  See attached screen grab for progress so far.

(In reply to Luke Kendall from comment #4)
> Created attachment 146908 [details]
> Obfuscating doc but regexp performance is now abysmal
> 
> I suspect this will be a hard to reproduce bug. It looks to me like data
> corruption in the structure used to hold runs of text.  I'll prepare the
> document anyway.
> 
> I'm preparing an obfuscated version of the document at the moment, by
> running a Find & Replace over the text by doing a Replace All (matching case)
> of [bcdfghjklmnpqrstuvwz] by x
> 
> F&R with this simple regexp is unacceptably slow.  It's been running for
> over 30 mins using 100% CPU.  After about 15mins it asked if I would turn
> off Undo so it could proceed.  I said Yes.
> 
> I'll leave it running overnight.  See attached screen grab for progress so
> far.

The performance for Find and replace will be better with LibO 4.4.7.2 (see bug 119286)

Created attachment 146934 [details]
The document in which the problem occurred, now obfuscated

Find&Replace performance was so bad it was basically unusable because I had change tracking and show changes turned on, and making a massive change (every consonant turned into an x).

But now it's apparently frozen trying to just start a save.
I can't close the F&R panel.  I killed it and started again with change tracking off.
F&R showed visible progress now, completing in about 5 minutes.

I have turned change tracking back on, and attached the sample document.
But I don't have reproduction steps for the problem, sorry.

Created attachment 146935 [details]
The render errors, now highlighted and numbered

The reason I suspected data corruption in the text run structure is because as well as the '!br0ken!!' text displayed there are errors in the rendering of the three lines before that.

I had replaced the name 'Gadger' with the name 'Wiz' and the text should be fully justified.
1. Instead that line ends with a "-" that does not appear in the actual text.
2. The same line starts with the text "me" instead of the text "some".
3. The following line also starts with a rendered space character " eyed", which again should not happen because of full justification.
4. There's a similar subtle problem on the line before the line I had edited - there is a space rendered after "For", despite the full justification. 

Hope this helps.

Luke, I had a look at this bug, but unfortunately I have no idea what to do, to reproduce the bug. To be honest, I even don't know what to do with your document from comment 6. Since this bug report has been untouched for half a year, I guess that other users have similar problems.

So could you give any hints or concrete steps to reproduce the bug? Is it still valid with the actual master?

=> I changed status to NEEDINFO.

Have you tried searching the source code for the occurrence of the strings:

"!broken!!"
"!br0ken!!"
or even just "!!"?

I would be looking for a use of this in code that could be called when displaying text in the main document canvas.

I was worried this would be hard to reproduce; this is my best suggestion after thinking about it for a while.

My guess is that this is a weird end-case and some programmer wisely decided to display the warning string instead of referencing through a NULL pointer or an uninitialised data structure it detected.  So based on this logic, my guess is the text string might occur in only a handful (or even just one) place in the entire source code.

What do you think?  Has anyone tried that?

(In reply to Luke Kendall from comment #9)
Bug 117155 might contain some pointers/ clues

It might be related I suppose.
But I only run spell check very infrequently.
In my case I think it happened by simply changing a word in the text.

I have one strong suggestion, and that is to change all the occurrences of the string !br0ken!! with a unique string across the source, at least !br0ken!!(1), !br0ken!!(2) etc. so the place in the source can be pinpointed.

Also, looking at the sample source in 117155 around the assert, and thinking of the problems that occurred for me after !br0ken!! appeared in my text, when not in debug mode perhaps a warning panel should be raised to the user to warn them to save the document and quit, and that the doc may have become corrupted?

Finally, regarding pinpoint the place in the code but also providing even more detail, I suggest it would be worth the few extra bytes of code to change

if ( count < 0 || beginIndex < 0 || beginIndex + count > pFrom->length )
{
        assert(false); // fail fast at least in debug builds
        IMPL_RTL_STRINGNAME( newFromLiteral )( ppThis, "!!br0ken!!", 10, 0 );
        return;
}

to something like:

if ( count < 0 || beginIndex < 0 || beginIndex + count > pFrom->length )
{

        assert(false); // fail fast at least in debug builds
        IMPL_RTL_STRINGNAME( newFromLiteral )( ppThis, "!!br0ken!!", 10, 0 );
        return;
}

Huh - it appears that typing TAB executed a SAVE instead of inserting a tab. I shouldn't be surprised.

What I was about to type was

if ( count < 0 || beginIndex < 0 || beginIndex + count > pFrom->length )
{
        assert(false); // fail fast at least in debug builds
        IMPL_RTL_STRINGNAME( newFromLiteral )( ppThis, "!!br0ken!!", 10, 0 );
        return;
}

should change to something like:

if ( count < 0 || beginIndex < 0 || beginIndex + count > pFrom->length )
{
        const static char *b1 = "!!br0ken!!(1.1)", *b2 = "!!br0ken!!(1.2)", *b3 = "!!br0ken!!(1.3)";
        assert(false); // fail fast at least in debug builds
        IMPL_RTL_STRINGNAME( newFromLiteral )( ppThis, (count < 0 ? b1 : (beginIndex < 0 ? b2 : b3)), 10, 0 );
        return;
}

Instrumenting the code so an accurate user error report gives you more information would in general make bug reporting and fixing easier for all concerned.  It would probably be worth the effort to start gradually doing that.

How great would it be to have semantic editors where you could instruct the editor to look for semantics and adjust the code for you according to a semantic restructuring pattern you described?  A programmer-assistive technology still 50 years away, maybe? :-)

@Luke Kendall
> Off Topic
How do you create these nice Obfuscated documents without disturbing the layout to much...

>Off topic

I replace every letter except capitals and vowels with x:

Find & replace

  Turn on Match case, and regexp:
  Find: ([bcdfghjklmnpqrstvwyz])
  Replace with: x
  Replace All

Some thoughts ...

1) The patch for bug 116725 (which also appears to have fixed bug 117155) isn't really for spellcheck per se, but rather fixes a problem when doing a right-to-left selection of justified text. Since your text is justified, and you didn't report the direction of selection you made, it's possible that this patch fixed the problem. See https://gerrit.libreoffice.org/#/c/52979/

2) In addition to the errors you noted in attachment 146935 [details], there was another in the original post that was not in the subsequent post. Specifically, the word "shrug" is lost in the original attachment. So it appears that the error began earlier. Also, it seems that the first exclamation point in !!br0ken!! has vanished. I suspect it's related to the notion that an extra word was added but the paragraph was not rejustified. I can see how that would mess up a renderer; I would not expect pile-on effects to crash the entire program, however.

3) I downloaded the obfuscated document and determined (by searching for "wix, ix xox") that the problem was on page 233. I tried doing some right-to-left highlighting and changing; no problems. Using version 6.2.6.2, build 6.2.6.2-1.fc30 on Fedora.

4) I suppose the bigger problem is not the arrival of "br0ken" but rather that Writer can crash when the text that led to "br0ken" is displayed. It appears that "br0ken" appears only once in the live codebase (see https://opengrok.libreoffice.org) so at least that's one fewer thing to worry about.

5) The display part of the bug can probably be closed and marked as fixed per my first paragraph above. It can always be reopened. 

6) To test the underlying problem (the crashing of the program), a programmer could force a call to that section of the code (/core/sal/rtl/strtmpl.cxx, line 1379) and see what happens. Above my pay grade.

Hello Luke a new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.

Ignoring the issue of trying to find where the error arises by logic, and given that this bug is extremely rare (I haven't encountered it for years now), I have a suggestion:

- change the error message include a warning like "Please save a copy of the file and restart, to avoid a potential crash."  At least that way the user should understand their danger and might avoid the potential disaster.

Then just resolve the bug as unreproducible?

no repro in 

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: c5ca46e75e28ba4245d8544ca53c71fea87d1bbd
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (ru_RU); UI: en-US
Calc: CL

@Luke
Stubbing on this bug again.. A couple of those bugs are fixed in the years.. is this still an issue?

(In reply to Telesto from comment #20)
> @Luke
> Stubbing on this bug again.. A couple of those bugs are fixed in the years..
> is this still an issue?

=> NEEDINFO

Also it would be practical to having a page number. It's impossible to find the area in the screenshot the obfuscated document

Dear Luke Kendall,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp