Issue 99029 - binary, encrypted, or compressed string into Writer may crash OOo
Summary: binary, encrypted, or compressed string into Writer may crash OOo
Status: CLOSED DUPLICATE of issue 99232
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0.1
Hardware: PC Linux, all
: P2 Trivial (vote)
Target Milestone: ---
Assignee: writerneedsconfirm
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-09 06:08 UTC by nicklevinson
Modified: 2009-02-15 13:44 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description nicklevinson 2009-02-09 06:08:19 UTC
When I was pasting texts into Writer, one text repeatedly caused Save As to
crash OOo, forcing logout before OOo could restart. I was pasting dozens of
texts into separate documents. What's different about this text is that it
included a very long string that is not in a human language, and therefore is
binary, compressed, or encrypted. The problem is in 2.4 but not in 2.0 Beta.

What I was doing in 2.4: Saving emails as text from my Yahoo account within the
Firefox browser:
--- In Firefox, open to my Yahoo email account's Inbox, go to a particular email
intending to copy a sequence of them, and set the displayed email to show Full
Headers, so all emails will show full headers.
--- With each email, when displayed, select all of the email and copy.
--- In Writer document with previously saved email, select all, delete, and
Paste Special the new clipboard contents as unformatted text from unknown source.
--- Save As. Prior settings were for Text Encoded as files to be shown and as
the format to apply to new saves and the destination directory on the removable
flash thumb drive was not changed. Filter settings were for ISO-8859-1 and
CR&LF, my usual, so I don't usually opt to see filter settings.

Sometimes, I had folders open on the desktop for the flash drive.

Exactly what happened at this point varied somewhat, but not much. I'd type the
filename as the number of the new email, in this case "75" (without quote
marks). Sometimes the previous file name, 74, would remain selected, with typing
doing nothing. I might once have gotten 75 into the filename field but not
progressed beyond that. In one attempt, screen redrawing was hindered; when
alt-tabbing through windows, some window boundaries refused to disappear and
erased pixels from the Writer document.

Then:
--- Waiting minutes made no difference.
--- The cursor, when hovering over Writer's document window or the save-as
dialog, would be an insertion point, but would be an arrowhead over desktop
non-OOo space.
--- I couldn't edit the filename field, Cancel the dialog, or select the File
menu to quit.
--- Switching to the Firefox window and coming back to Writer did not clear
anything up.
--- Force Quit, via Gnome 2.10.0 desktop panel button, applied to Writer.
--- Restarting Writer from the Main Menu yielded nothing, not even the OOo
splash screen.
--- Starting Calc, which I had used in the past week, also yielded nothing, not
even a splash, despite waiting.
--- Starting Imendio Planner 0.13, a non-OOo application in the same Office
submenu of the Main Menu, was fine, so the submenu was working.
--- Saving the problematic text into gedit 2.10.2 worked fine. Settings were
charset 8859-1 as above, to show text files rather than all files, and the same
destination; I named the file "75" (without quote marks), as above, albeit not
75.txt as I should have (Writer automatically adds the extension). (gedit is not
my preferred solution since Writer formats text better.)
--- Either rebooting or logging out and back into the same user nonroot account
was sufficient to allow restarting Writer 2.4.

After a few failures following the above, I went to the next email and
successfully saved it and all the ones after that, all with Yahoo's Full Headers
on, in Writer as "76", "77", and "78" (all without quote marks), with my
customary settings.

A similar procedure in OOo 2.0 Beta (version 1.9.104) Writer on the same machine
succeeded in saving. Thus, the issue was introduced after 1.9.104 and before or
in 2.4. OOo 2.4 was not open. Keeping the procedure as similar as possible
(considering that 2.4 adds features), I used a copy of a previously saved email
copy (named "75 (copy).txt") to replace its contents and save-as under a new
number (99.txt) and saved as Text Encoded. When exiting 2.0, a force-quit dialog
briefly appeared but without input from me Writer promptly exited; the
appearance of that dialog and fast self-operation is not unusual on my setup and
doesn't seem alarming, work already having been saved.

After the success with 2.0 Beta, I exited 2.0 and tried again with 2.4, but
failed again. Alt-F would not open the File menu for saving. The cursor was an
arrowhead. No menubar menu would open. Alt-space did open the service menu,
which I didn't use, and the Minimize button worked, but alt-tabbing or clicking
the panel icon (I forgot which I did) to unminimize resulted in a redrawing
problem again, this time the Writer window showing the contents of the Firefox
window at the same time that the Firefox window also showed the contents of the
Firefox window, only the title bar differing, even when I moved Firefox down to
the next workspace. Moving it was via the service menu command to go down, which
succeeded after the service menu's submenu to select the same workspace by
number failed to let me select a command, whereas that latter submenu worked
later in the same login session on a different Writer document. When Firefox was
in the other workspace, Writer was visible only as a title bar; I could see the
desktop wallpaper.

To eliminate that the problem is not file length per se but the content, I took
a file that had been successfully saved in 2.4 and copied and repeatedly pasted
some of its message content until the file length was 23 pages long, or 3 pages
longer than the problematic file. The 23-page file successfully saved-as. Thus,
the 20-page length of the problematic file is not the problem.

About 1-2 years ago, I used to do a similar procedure into a recent version of
Microsoft Word and Word would crash, whereas an earlier Word would not and
non-MS software would accept the same emails without a problem. At the time, I
suspected that Yahoo's banner ads might be clashing with Word. Assuming that's
correct, that wouldn't apply here, since I successfully pasted all 78 except #75
itself and failed with #75 despite logging into Yahoo anew several times, so
it's likely the ads rotated and that any ad appearing on #75 may have appeared
with other emails that I successfully pasted-special into Writer. So we can
probably ignore the banners and any associated Java or JavaScript.

So, the analysis of #75 is germane. That email was an email delivery failure
notice which included part of the email that I had tried to send someone else.
The attempted email included a very short message and 2 spreadsheets made in OOo
2.4 Calc, one formatted as Excel 97/2000/XP. The spreadsheets were made in the
same installation on the same computer; reboots have intervened since. The
failure notice, which was due to "message size exceeds limit" (apparently a
limit at the recipient's email service provider) and came more than 24 hours
after I had sent the original email, quoted my message (brackets indicate my
omissions here):

--0-199329798-1228970117=:46680
Content-Type: text/plain; charset=us-ascii
[. . . . .] [English plaintext]

--0-199329798-1228970117=:46680
Content-Type: application/vnd.ms-excel; name="[. . .].xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="[. . .].xls"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAABt
[. . . . .]
MjEtYSBsaXN0IC

--- End of message stripped.

That's the end of the failure notice. Apparently, the Calc file that was not
converted into Excel was not quoted in the failure notice, only the Calc
Excel-formatted one was, and only in part (the original attachment was 6-7MiB
long). The filename represented here by brackets was spelled with letters,
numerals, hyphens, and spaces only and was the same with both bracketings above
next to .xls. The bracketing below that is for your system's safety; the omitted
text seems to have crashed OOo, and I don't want to crash your system. It
represents about 729 lines, each (assuming a monospaced or fixed-pitch font) 60
characters long plus perhaps some kind of a newline for each line, thus about
43,740 characters omitted here plus newlines, for a total of 43,814 characters
plus newlines in the string in the failure notice, probably none of them spaces.

It appears the string is compressed, encrypted, or binary or some combination
thereof.

Somehow, this string, and perhaps others like it, is causing OOo, not just
Writer, to crash during Save As.

If you want a copy of the string, let me know. I'll try to send it in a safe
way, perhaps as a compressed file or as an image of the text. However, you'll
have to be responsible for any risks attendant on getting and using it, since I
can't be once it leaves. You should also let me know if you want it sent in such
a way that it won't be posted on the website, if you would prefer that it not be
downloaded by the public from your website.

I'm running Fedora Core 4 Linux with Gnome 2.10.0 desktop and Firefox 1.0.4.
Except as noted above, I was not running other applications visible in a panel
unless they always run. I did not install Java Runtime Environment (JRE) with OOo.

No retroactive bug fix is proposed by me, just a fix for future versions.

Thank you.

-- 
Nick
Comment 1 michael.ruess 2009-02-09 09:17:42 UTC
I cannot reproduce this using OOo 3.0 or 3.0.1 and Firefox 3.0.6.
Could you please upgrade and see again? There won't be any more fixes for OOo 2.x.
Thanks for your patience.
Comment 2 michael.ruess 2009-02-09 09:19:20 UTC
BTW: this is not a P1 issue.
closed.
Comment 3 nicklevinson 2009-02-11 07:19:57 UTC
It still crashed, so I've reopened this issue.

I installed 3.0.1. I used gedit to open the suspect email text copy and 2
nonsuspect email text copies (one earlier and one later), each in a separate
gedit document. With each, I selected all, copied, alt-tabbed to Writer 3.0.1,
pasted, and scrolled to the top. With the nonsuspect texts, I could scroll down,
too. But the suspect text did not allow scrolling down because the insertion
point had frozen. Menubar menus refused to open. Only the service menu opened
and worked, and I used it to move the WEriter document to the next workspace
down, but there only the titlebar showed up. The close box produced the Force
Quit dialog.

That's similar to what happened with 2.4.0 in a retest like the above, with
freezing taking different forms, including in one case the disappearance of
scroll bars, the menubar, and all toolbars.

I did not customize 3.0.1. If installing it carries customizations forward from
2,.4, then those were present.

Closing gedit after pasting into Writer 3.0.1 but before trying to scroll up
made no difference.

The browser doesn't matter. Copying from gedit 2.10.2 also causes the crash.

My guess as to the cause is that a string is used by Writer or OOo for an
internal meaning, and the string's coincident appearance in pasted or typed text
confuses Writer or OOo. If so, the solution is to code OOo or Writer to alter
how the user-supplied string is represented internally so OOo or Writer does not
see it literally and then restore it when saving, displaying, or printing, so
the user never learns of the change in representation. That raises a risjk that
a user will inseryt a string that coincides with the altered form; the solution
to that is to create on the fly a delimiter having no other meaning within OOo
or Writer and not found in the user's input and then not attempt to restore
whatever is so delimited.

I now withdraw my offer to send you the string, since I now wonder if it might
contain confidential content. Instead, to support open source coding and
research, perhaps one of us could create a 7-10MB Calc spreadsheet with
formulas, convert it to Excel 97 format, attach it to an email to an appropriate
recipient (the best is a real recipient whose account has an under-10MB limit on
an attachment to be received and the second best is a real domain with a fake
username), email it from a Yahoo account, await the delivery failure (which
might take up to 5 days), hope the attachment is returned inline (not as an
attachment any longer) and represented internally as a gob of gibberish, and see
if the new gob crashes Writer like the old gob did. If you want me to create the
spreadsheet, let me know where to send it and what the attachment size limit is.

As I noted in my first post, I wasn't requesting a repair to 2.x, only for
future versions if it hadn't already been fixed in the interim, and it hadn't been.

As to P2/P1, I did another test in OOo 3.0.1: I opened both Calc and Writer and
induced the crash. Crashing Writer also crashed Calc. So, it crashes "the whole
product" (http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority).
That makes it P1. And, also because 2 apps crashed from 1 pasting, I changed the
component from WEriter to framework. I also updated the OOo version on this report.

Thanks.

-- 
Nick
Comment 4 michael.ruess 2009-02-12 13:55:18 UTC
P2 is for issues "making the whole office unusable. Thus it is P2; OOo crashes
in a point, but it is not fully unusable..

MRU->CMC: this happens on FC4 with Firefox 1.04. Can you imagine what might be
wrong here?
Comment 5 caolanm 2009-02-12 14:09:47 UTC
Not really, Fedora Core 4 itself is pretty old, so if 3.0.1 is in play then its
the "vanilla" 3.0.1 not the old OOo release that went out shipped with FC4. 

Without a route to reproduce (I didn't see one here, but perhaps I missed it),
or a backtrace, its hard to say what it could be. One topical possibility is
that the text contains characters that cannot be drawn with any installed font
and so falls into the bug of #i99081#, but I only mention that as an example of
the type of crash that it may be.
Comment 6 nicklevinson 2009-02-12 17:55:46 UTC
The browser is irrelevant. The problem also happened without a browser, when I
copied from gedit into Writer.

The font was gedit's default font (gedit simply says Monospace), and was an
ordinary text font. That seems to eliminate the problem of not being able to
draw the font. The culprit appears to be the string itself, or in it.

I downloasded OOo 3.0.1 from OOo's website and did not customize it before the
test (I have since). The OOo that came with FC4 was 2.0 Beta and it did not have
the problem; 2.4, which I had downloaded from OOo's website, did, as did 3.0.1.

No backtrace was shown. On a restart of OOo, if recovery is offered and
attempted, a crash report is offered but has never shown up.

OOo crashes and disappears completely. The problem with Writer also took Calc
down. Writer can be restarted and recovery mode begins. At any rate, I'll accept
the P2 decision.

I don't know enough to analyze issue 99081.

I have to leave now, but probably tonight I'll rewrite the reproduction path for
clarity. It's in this issue but due to the retesting it's now in 2 posts.

Thank you.

-- 
Nick
Comment 7 caolanm 2009-02-12 18:09:59 UTC
"The font was gedit's default font (gedit simply says Monospace), and was an
ordinary text font. That seems to eliminate the problem of not being able to
draw the font. The culprit appears to be the string itself, or in it."

Not really, it doesn't always quite work that way, i.e. its just "raw text" when
copied from gedit, the font doesn't come with it so if there was a missing glyph
there could be two different fonts, and two different font-replacement
technology stacks in operation, the gedit one (which doesn't crash) and the OOo
one (which did). Anyway, its probably not that issue, I only mentioned it as a
example.

If you have a text file which reproduces this then just attach it here and we
can have a look at it. If its confidential, and you trust us :-), then you can
send it to either myself (cmc@openoffice.org) or I'm sure mru@openoffice.org
would also be willing to test it out-of-band
Comment 8 nicklevinson 2009-02-13 08:06:20 UTC
I've emailed a file for testing (to cmc & cc: mru). It's not confidential, but,
until or unless we understand more, it should be considered dangerous to
existing data, so I emailed it compressed and I don't want to put it on an open
site. However, you may post it if you conclude that it's not a danger or that
only reasonably cautious people who will take responsibility for fixing their
own computer systems will handle it.

Here's a replication procedure:

1. Decompress the file. (I believe it's safe while in its compressed state.)

2. Open in gedit or, probably, any text editor.

3. Open Calc and Writer in OOo 3.0.1.

4. Select all in the gedit file.

5. Copy from gedit.

6. Paste into Writer.

7. Page up to the top and then back down.

Within a handful of seconds, the screen will freeze. Page Up, Page Down, and
scrolling will fail. The insertion point won't move. No menus will open except
the service menu in the title bar. If you use the service menu to move the file
to another workspace, it will move but only the titlebar will be visible. Alt-F4
will produce a Force Quit alert. If you okay Force Quit, all of OOo will disappear.

Two new facts:
--- The encoding, according to an email service, is base64.
--- This long string is not identical to the string that was originally
discussed, yet the effect is the same. That it's not the same string is due to
my having made a new (nonconfidential) spreadsheet (available on request), with
different content, and emailing it to an address that wouldn't likely exist,
causing an immediate bounce, in which the bounce message included this very long
string evidently generated from the spreadsheet file.
--- I was able to restart OOo during the same Linux login session, which is an
improvement from the experience in my first post above. Thus, something in what
I did the first time had the additional effect of preventing program restart
without an intervening login, but maybe solving the narrower problem will moot
the restart one.

Thanks again.

-- 
Nick
Comment 9 caolanm 2009-02-13 09:36:16 UTC
Works fine for me with 3.0.1, no hang no crash. I wonder if it makes any
difference to deselect auto-spellchecking in the menu bar before pasting it in.
Comment 10 nicklevinson 2009-02-14 20:15:42 UTC
That's it (probably)! You narrowed the problem. I tested it without and with
spelling and grammar checks.

Since that identifies a new problem (no word is over 60 characters yet it jams
up), I'm opening a new issue and about to close this one. I could change the
title here but not the leading posts, so, to make it easier to understand, I'll
open anew and refer back to here for some details. The zone of doubt left will
be discussed there.

Thanks for the idea.

-- 
Nick
Comment 11 caolanm 2009-02-14 20:23:37 UTC
Next thing is to let us know what language is being spell and/or grammar
checked. In my own case I tried with a en_GB (aliased to en_IE) spell-checking
dictionary without a noticeable problem.

I would suggest setting this issue as a duplicate of your new issue that
spell-checking/grammar-checking those 60 letter random words makes something hang.
Comment 12 nicklevinson 2009-02-14 21:18:54 UTC
I use en-US.

Thanks.

-- 
Nick
Comment 13 nicklevinson 2009-02-14 21:36:57 UTC
I'm trying again to mark this as a duplicate of issue 99232. If it still doesn't
succeed, either the radio option and the fill-in field aren't the way or I don't
have the authority. Please let me know how or go ahead and do it.

Thanks.

-- 
Nick
Comment 14 caolanm 2009-02-15 13:42:51 UTC
set as duplicate

*** This issue has been marked as a duplicate of 99232 ***
Comment 15 caolanm 2009-02-15 13:44:50 UTC
close as dup, toggling spell/grammar checking off makes it not happen