Bug 137692 - [x86_64] gnumeric picks up unprintable characters
[x86_64] gnumeric picks up unprintable characters
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnumeric (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-30 15:22 EDT by Michal Jaegermann
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: FC3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-09 13:28:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a sample Excel file which demonstrates the issue (22.50 KB, application/octet-stream)
2004-10-30 15:23 EDT, Michal Jaegermann
no flags Details
An Excel file which is causing segmentation fault (16.50 KB, application/octet-stream)
2004-10-30 17:53 EDT, Michal Jaegermann
no flags Details
x86_64 compilation log (797.47 KB, text/plain)
2004-11-01 14:41 EST, Caolan McNamara
no flags Details
ia64 log (787.04 KB, text/plain)
2004-11-01 14:42 EST, Caolan McNamara
no flags Details

  None (edit)
Description Michal Jaegermann 2004-10-30 15:22:45 EDT
Description of problem:

While reading .xls files produced by Excel gnumeric apparently
"reaches" beyond a field width and picks up various unprintable
characters.  This is not only messing up display but affects
also printouts, and other conversions, where some pieces of
an expected printout vanish while some other characters, deemed
obviously "printable", are messing up results.  Earlier versions
of gnumeric were lacking this "feature".

Saving in a native gnumeric format helps to remove quite a bit
of this garbage but, unfortunately, not all of it.  Also when
saved as LaTeX file this ends up with results which are causing
complaints "Keyboard character used is undefined ....
l.242 ...Velvia Reciprocity Correction^^A^^B^^F}}}" and the like.
One has to run results through a filter of

    tr -dc '[:print:]\n'

kind before achieving something close to a LaTeX source file.
All in all a serious PITA.

Version-Release number of selected component (if applicable):
gnumeric-1.2.13-6

How reproducible:
On all .xls files I tried so far
Comment 1 Michal Jaegermann 2004-10-30 15:23:58 EDT
Created attachment 105981 [details]
a sample Excel file which demonstrates the issue
Comment 2 Michal Jaegermann 2004-10-30 16:17:26 EDT
Opening the same .xls file in 'oocalc' one is not getting extra
"appendages" in spreadsheet fields. An embedded graph looks much
worse, though.
Comment 3 Michal Jaegermann 2004-10-30 17:42:35 EDT
I found also that if one does some edits to a demo file, say
removing unwanted "characters" and will attempt to save results
in the same format as the original then gnumeric will spit on
a screen a lot of mesages like

** (gnumeric:13415): WARNING **: This is somewhat corrupt.
We already wrote a length for a string that is being truncated due to
encoding problems.
Leaking gnm-format at 0x9e1200 [General].

** (gnumeric:13415): CRITICAL **: file go-font.c: line 33
(go_font_free): assertion `font->ref_count == 1' failed

and it will stop.  Whatever was saved it cannot be reloaded
because of "Unsupported file format".

With some other file and similar operations (edit and save
in the original format) one can get:
......
** (gnumeric:13489): WARNING **: hmm we could not represent character
0xffffffff, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0xffffffff, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0x0, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0x0, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0x0, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0x0, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0x30, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0x0, skipping it.

** (gnumeric:13489): WARNING **: hmm we could not represent character
0x0, skipping it.
Segmentation fault

and only an empty file like .gsf-save-akPsV0 will show up.

Comment 4 Michal Jaegermann 2004-10-30 17:53:39 EDT
Created attachment 105984 [details]
An Excel file which is causing segmentation fault

This is a sample file to crash gnumeric in a way described in comment #3.
It seems that what will happen is a particular sample dependent; but even
if a save after edit-out succeeded then "garbage characters" are back
in a saved material.
Comment 5 Michal Jaegermann 2004-10-30 18:45:53 EDT
Ouch!  I should have thought about that earlier.  All the trouble
above happens on x86_64 but not x86.  This rather clearly points
out where bugs may be and also why oocalc does not have problems. :-)
OTOH older gnumeric versions did work on Alpha ...
Comment 6 M Welinder 2004-11-01 13:53:14 EST
Possibly a type error in ms_biff_get_chars.  Can we get a compilation
log for gnumeric on x86_64, please?

Comment 7 Caolan McNamara 2004-11-01 14:41:28 EST
Created attachment 106041 [details]
x86_64 compilation log
Comment 8 Caolan McNamara 2004-11-01 14:42:52 EST
Created attachment 106042 [details]
ia64 log
Comment 9 Andreas J. Guelzow 2004-11-01 17:22:22 EST
fixed in gnumeric 1.3.92
Comment 10 Caolan McNamara 2004-11-02 07:39:09 EST
backported to rawhide and fc3
Comment 11 Caolan McNamara 2004-11-09 13:28:55 EST
Should be good in gnumeric-1.2.13-8.fc3
Comment 12 Michal Jaegermann 2004-11-11 00:41:10 EST
In all my test cases gnumeric-1.2.13-9 from rawhide, actually
recompiled to work with python-2.4-0.b2.3, behaves on x86_64
without any nasty surprises (but see bug #138742 about recompilation
issues).

Note You need to log in before you can comment on or make changes to this bug.