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

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).

*** Bug 47552 has been marked as a duplicate of this bug. ***

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 ?

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.

Created attachment 58919 [details]
Font required

I am posting font required here for anyone who could not get it from the web.

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.

(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)?

There may be a relation to bug 44094 - "CRASH when viewing fonts and selecting a specific font (Quinquefoliolate)".

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.

Created attachment 61537 [details]
Portable libre office 3.3 legacy

Document opened in Portable libre office 3.3 legacy

Created attachment 61538 [details]
Portable libre office 3.5.2

Document opened in Portable libre office 3.5.2

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.

@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 ...

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.

(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).

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.

Created attachment 61551 [details]
softmaker office 2008

Also i found this office suite (softmaker office 2008) Text Maker to read data reasonably well.

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.

(it looks like GNU/Linux has already been excluded, but I'm

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 !

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.

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.

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...

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.