Bug 47553 - FILEOPEN document with Punjabi Font will CRASH
Summary: FILEOPEN document with Punjabi Font will CRASH
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other Windows (All)
: medium major
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: BSA bibisected35 bibisected35newer ta...
Keywords: regression
: Kvwriter (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-20 01:24 UTC by Kunal
Modified: 2015-11-07 08:50 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
File which i created in ver 3.4.5 but crashes in 3.5 . (17.37 KB, application/vnd.oasis.opendocument.text)
2012-03-20 01:24 UTC, Kunal
Details
Font required (50.39 KB, application/x-font-ttf)
2012-03-23 05:02 UTC, Kunal
Details
Portable libre office 3.3 legacy (66.55 KB, image/jpeg)
2012-05-12 19:57 UTC, Kunal
Details
Portable libre office 3.5.2 (76.00 KB, image/jpeg)
2012-05-12 19:58 UTC, Kunal
Details
Portable open office 3.2 (84.63 KB, image/jpeg)
2012-05-12 20:00 UTC, Kunal
Details
Installed Libre Version 3.4 (78.16 KB, image/jpeg)
2012-05-13 05:09 UTC, Kunal
Details
softmaker office 2008 (73.05 KB, image/jpeg)
2012-05-13 05:12 UTC, Kunal
Details
Bug 47553 - WinDbg session (11.35 KB, text/plain)
2012-06-04 03:42 UTC, bfoman (inactive)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kunal 2012-03-20 01:24:26 UTC
Created attachment 58728 [details]
File which i created in ver 3.4.5 but crashes in 3.5 .

Problem description: When i open file ( created successfully in libre office version 3.4.5 ) it crashes ( in version 3.5.1)

Steps to reproduce:
1. Open file created in ver 3.4.5 with external font Asses ( an Indian lang Punjabi Font).
2. It crashes with file for recovery lefted
3. Behavior seen in only version 3.5.x

Current behavior:Crashes

Expected behavior:Should not carsh

Platform (if different from the browser): Win XP
              
Browser: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Comment 1 Rainer Bielefeld Retired 2012-03-20 03:32:26 UTC
Crash is [Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) and
LibO 3.4.5 and LibO 3.4.1 RC1

I can open document with "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]"; shows only rectangles instead of characters, but does not crash.

Looks very similar to "Bug 45355 - CRASH if characters in text of BENGALI, TIBETAN, MALAYALAM, MARATHI, NEPALI, ORIYA, TAMIL, TELUGU"

@Reporter:
Ar you sure that that works for you with 3.4.5? My versions after 3.3 all crash
Comment 2 Julien Nabet 2012-03-20 14:43:48 UTC
No crash on pc Debian x86-64 with master updated today. (no specific error/warn messages)

(compiling 3.5 branch right now, so can't tell for 3.5 for the moment).
Comment 3 Julien Nabet 2012-03-20 14:50:55 UTC
*** Bug 47552 has been marked as a duplicate of this bug. ***
Comment 4 Julien Nabet 2012-03-20 15:07:50 UTC
I don't reproduce it with 3.5 branch (so not exactly 3.5.1).
Perhaps a Windows specific bug ?
Could someone try on MacOs ?
Comment 5 Kunal 2012-03-23 05:00:39 UTC
I can open it in version 3.4.4 successfully without any crash but though some scrambled characters are there.Also i remembered that i created this document in previous version then 3.4.4 don't remember which exactly probably openoffice version 3.3 or 3.2 which i used before coming to libre office as development of open office stopped.
If required i can post screen shots and font (asses) required to open readable info.
Comment 6 Kunal 2012-03-23 05:02:30 UTC
Created attachment 58919 [details]
Font required

I am posting font required here for anyone who could not get it from the web.
Comment 7 Kunal 2012-03-23 05:06:20 UTC
Sorry fonts are just if need be because most of my document are in this fonts i personally did not verified it if that required with this document i posted as i would not be available for months due to my job.
Comment 8 Roman Eisele 2012-04-21 07:12:14 UTC
(In reply to comment #4)
> Perhaps a Windows specific bug ?
> Could someone try on MacOs ?

It looks like a Windows-specific bug: I can open and edit the provided sample file without any problems both with LibreOffice 3.4.6 and 3.5.2.2, both with German UI, both running on MacOS X 10.6.8. No crash, no problems. I have installed the font (Asses) before.

NB: The MacOS X Fontbook application reports some minor problems with the Asses font: structure and content of the 'kern' table are not OK. FontLab opens the font file without problems, but shows only one single kern pair; this looks, well, strange, and may be the sign of a damaged 'kern' table which FontLab could not import completely.

Is it possible that font kerning problems cause the crash on Windows (but not on MacOS or Linux)?
Comment 9 Roman Eisele 2012-05-08 01:41:23 UTC
There may be a relation to bug 44094 - "CRASH when viewing fonts and selecting a specific font (Quinquefoliolate)".
Comment 10 Kunal 2012-05-12 19:56:44 UTC
I recently open this document with libre office portable version 3.3 (or LibreOfficePortableLegacy33)and it works fine shows all.
Then i used and open document in open office portable version 3.2 it works fine
I then open it in libre office 3.4.4 installed and 3.5.2 portable version which did not crash but show scrambled charcters.Posting screenshosts of each.
So this led me to concluded it not window specific bug but a odf 1.1 specification to odf 1.2 specification incompatiblity especially with Punjabi language.
Hope i am right.
Comment 11 Kunal 2012-05-12 19:57:47 UTC
Created attachment 61537 [details]
Portable libre office 3.3 legacy

Document opened in Portable libre office 3.3 legacy
Comment 12 Kunal 2012-05-12 19:58:44 UTC
Created attachment 61538 [details]
Portable libre office 3.5.2

Document opened in Portable libre office 3.5.2
Comment 13 Kunal 2012-05-12 20:00:17 UTC
Created attachment 61539 [details]
Portable open office 3.2

Document opened in Portable open office 3.2 
Exactly i wanted it to be displayed 100% correct.
Comment 14 Roman Eisele 2012-05-12 23:06:15 UTC
@Kunal:
Thank you very much for your additional tests!

(In reply to comment #10)
> So this led me to concluded it not window specific bug [...]

IMHO the bug (or "incompatibility", as you say) looks still Windows-specific, because it seems to happen only on Windows -- cf. comment #2, comment #4, comment #8. (By "Windows-specific", we don't mean a bug in Windows itself, but a bug which appears only in the Windows version(s) of LibreOffice.)

*

Added 'regression' keyword according to comment #1 and comment #10 (no problems, at least, in 3.3; no agreement about 3.4.x).

Set 'Status' to NEW, because I don't see which info we need from the reporter etc. for now -- we may need some debugging, of course ...
Comment 15 Rainer Bielefeld Retired 2012-05-13 00:19:16 UTC
Parallel installation of Master "LOdev 3.6.0alpha0+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 9980e69]" (tinderbox: Win-x86@6-fast, pull time 2012-05-10 09:36:56) still crashes.

I believe that "scrambled characters" problem is something different, a new Bug with reference to the sample document and screenshots here should be opened.

@Cédric:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug.
Comment 16 Roman Eisele 2012-05-13 01:39:08 UTC
(In reply to comment #15)
> Parallel installation of Master "LOdev 3.6.0alpha0+  – WIN7 Home Premium
> (64bit) ENGLISH UI [Build ID: 9980e69]" (tinderbox: Win-x86@6-fast, pull time
> 2012-05-10 09:36:56) still crashes.

Just a hint:
Still a Windows-specific problem -- no crash on MacOS X 10.6.8 German UI with LOdev version 3.6.0alpha0+ (Build ID: 9e536d2; installation file: master~2012-05-11_06.13.05_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US.dmg).
Comment 17 Kunal 2012-05-13 05:09:10 UTC
Created attachment 61549 [details]
Installed Libre Version 3.4

Document opened in Libre office 3.4 is same and incorrect display as with version in 3.5.2.
This made me to conclude that it conversion of specification of odf 1.1 to odf 1.2 that makes difference lost or scramble charters especially in punjabi language so document written in previous version prior 3.4 may not display well.
So advise is to have at least portable version of legacy office suite.
ALSO GUYS FONT IS NOT REQUIRED WITH DOCUMENT (forward1.odt)I VERIFIED IT.
Comment 18 Kunal 2012-05-13 05:12:36 UTC
Created attachment 61551 [details]
softmaker office 2008

Also i found this office suite (softmaker office 2008) Text Maker to read data reasonably well.
Comment 19 bfoman (inactive) 2012-06-04 03:42:51 UTC
Created attachment 62495 [details]
Bug 47553 - WinDbg session

Confirmed with:
LO 3.5.4.2 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Crash while loading (font not installed).

Attached full WinDbg session with mini dump file loaded generated by procdump soffice.bin -h.
Comment 20 Robinson Tryon (qubit) 2012-07-03 15:05:43 UTC
(it looks like GNU/Linux has already been excluded, but I'm
Comment 21 Michael Meeks 2012-12-18 15:07:08 UTC
bfoman - thanks for this:

00bedcc8 5d9b8d09 00bedcf0 ffffffff 21a577b1 vcllo!std::vector<bool,std::allocator<bool> >::operator[]+0x28 [c:\program files\microsoft visual studio 9.0\vc\include\vector @ 2091]
00bedfa4 5d88610a 00bee02c 0000000c 00000013 vcllo!MultiSalLayout::AdjustLayout+0xd69 [d:\losrc\3542\vcl\source\gdi\sallayout.cxx @ 1856]
00bee098 5d884e0d 059971b8 00000000 00000004 vcllo!OutputDevice::ImplLayout+0x55a [d:\losrc\3542\vcl\source\gdi\outdev3.cxx @ 6070]
00be

    // Compute rtl flags, since in some scripts glyphs/char order can be
    // reversed for a few character sequencies e.g. Myanmar
    std::vector<bool> vRtl(rArgs.mnEndCharPos - rArgs.mnMinCharPos, false);

I guess we're reading out of bounds in that vector. It'd be nice to re-test this on master, so we can get line numbers better synch'd but I guess that really it crashes on:

        if (bRtl) std::fill(vRtl.begin() + (nRunStart - rArgs.mnMinCharPos),
                            vRtl.begin() + (nRunEnd - rArgs.mnMinCharPos), true);

dtardon's fix to add the () around the offset calculations might have fixed this - but that happened before 3.5.x so ... really unclear what's going on there.

Any chance of some debugging foo there bfoman ? we would need:

vRtl.size()
the contents of all members of rArgs, the values of nRunStart and nRunEnd.

Thanks !
Comment 22 Not Assigned 2012-12-22 01:08:02 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cec68bceba9aa1e984d74897fcd7bf4db702d14b

fdo#47553: UniscribeLayout: adjust mnSubStringMin



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 23 Not Assigned 2012-12-22 01:14:19 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5938e1c3de3a7e55719eb47e2e87666189ed222&g=libreoffice-4-0

fdo#47553: UniscribeLayout: adjust mnSubStringMin


It will be available in LibreOffice 4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 24 Michael Stahl (allotropia) 2012-12-22 01:21:25 UTC
interesting... this appears to call some MSVC runtime assertion facility,
which is (since bug 38913) hooked by a invalidParameterHandler
function in sal/osl/w32/salinit.cxx, so it does not crash any more
but prints out many lines of "Invalid parameter in ???" lines.

problem is in Windows-only UniscribeLayout apparently.
GetNextGlyphs returns -1 character position, which is then used as index.

...

it appears that the way in which the mnSubStringMin is initialized that
is used in the fix for bug 33090 is mostly guesswork, and when the
guessing doesn't match reality the wrong array entries are written.

strangely the bugdoc does not actually seem to use the attached font,
after fixing this to not crash i get lots of empty squares on windows
even after copying the font to c:/windows/fonts...
Comment 25 Not Assigned 2013-01-02 12:27:06 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=49dcb4794c838d5f1cf61060f216fc67f36c1618&h=libreoffice-3-6

fdo#47553: UniscribeLayout: adjust mnSubStringMin


It will be available in LibreOffice 3.6.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.