Reproduced on Windows XP (SP3) / 3.3RC4.
The crash does not occur when searching it in "Find & Replace" Dialog,
but does with "Find" toolbar.

confirmed. Tor can you take a look please?

Ha, again the same assertions as in bug #33407: sw/source/core/txtnode/ndhints.cxx, line 389.

I see that already in bug #32275 , in comment https://bugs.freedesktop.org/show_bug.cgi?id=32275#c6 , I was looking at this same assertion. Presumably these three bugs are all aspects of the same problem?

I also see assertion failures from sw/source/filter/ww8/ww8par6.cxx, line 3672, "no charset to remove". 

If I click away dozens if not hundreds of times on the "No" button to ignore the assertions, ignoreing the risk of repetitive stress injury, after the progress bar has finished, but before anything is displayed, I eventually get a lots of  even funnier assertion failures: sw/source/core/text/guess.cxx, like 182: "What a Guess!!!" Whee, humour!

After clicking away those a couple of dozen times my index finger was exhausted and I had to stop.

(In reply to comment #3)
> Ha, again the same assertions as in bug #33407:
> sw/source/core/txtnode/ndhints.cxx, line 389.
> 
> I see that already in bug #32275 , in comment
> https://bugs.freedesktop.org/show_bug.cgi?id=32275#c6 , I was looking at this
> same assertion. Presumably these three bugs are all aspects of the same
> problem?
> 
> I also see assertion failures from sw/source/filter/ww8/ww8par6.cxx, line 3672,
> "no charset to remove". 

caolan, could you check those? I don't feel really comfortable with the font code definitions in WW8 formats...

> If I click away dozens if not hundreds of times on the "No" button to ignore
> the assertions, ignoreing the risk of repetitive stress injury, after the
> progress bar has finished, but before anything is displayed, I eventually get a
> lots of  even funnier assertion failures: sw/source/core/text/guess.cxx, like
> 182: "What a Guess!!!" Whee, humour!

Well, temporarily commenting out the "no charset to remove" assertion could save you loads of clicks. I have those assertions here on linux too. But the last one you are refering at I don't have it. Would there be some strange thing in the line breaks computations? Do you have a backtrace of the crash?

> temporarily commenting out the "no charset to remove" assertion could
> save you loads of clicks

Can the assertion in fact be removed then, if it doesn't show anything that would *immediately* cause a crash? What is the point with it?

Or alternatively, is it the first assertion failure that needs to be investigated, and that the program does manage to run for quite a while afterwards just a coincidence?

I have a real problem to understand how assertion failures in LO code are to be interpreted...

re:
"
I also see assertion failures from sw/source/filter/ww8/ww8par6.cxx, line 3672,
no charset to remove. 
caolan, could you check those?
"

this is due to SwWW8ImplReader::CorrectResIdForCharset introduced without comment or explanation with commit 3d047bb3 back in July 2010 which has mangled the CJK_FONT vs nonCJK font value, causing the non-cjk font's charset to be pushed onto the cjk charset stack instead. So the assert is correct. 

If we retain SwWW8ImplReader::CorrectResIdForCharset we need to modify it to push the charset to the correct place when doing that mangle. Personally I suspect that SwWW8ImplReader::CorrectResIdForCharset is kind of bogus and a hack to attempt to workaround some problem. So, I've removed SwWW8ImplReader::CorrectResIdForCharset

Though before or after has no effect on this bug I believe. Unfortunately I can't reproduce it under Linux and master, nor see anything in valgrind to hint at what it might be.

Modify Status due to facts.

Double-checking, still can't reproduce under Linux with a11y enabled either.

I tested on Windows 7 with LO 3.5.2 and bug not reproducible. Please check.

Seems to be gone on 3.5.2 under windows for me as well