The same issue was reported in Korean community.

Calc crashed when Format > Cell was chosen on context menu and when Microsoft
Office IME 2007 was default. The problem went away once IME was changed to the
default Windows 7 IME.

Reproduced in the following combination:

* Windows 7 x86(32bit) Japanese
* Microsoft Office IME 2010

To avoid crash:

setting soffice.exe under compatibility mode "Windows 98/Windows Me" or "Windows
95" worked in my case.
however, this tweakaround may result in some minor problems in OOo system-wide
usability.
the following are some of those I found:
* Hovering pointer from a menu group to another results closing of the menu.
* Presentation takes long time to start a new project.
* There're some cases where OLE D&D between OOo and another application fails.

*** Issue 110795 has been marked as a duplicate of this issue. ***

Under the same condition that is the same as that of matuaki, I couldn't even open 
the "Format Cells" dialog. Calc crashed then, this is probably because "Number" 
tab is the default tab that is shown first when I open the dialog.

If anyone doesn't dedicate herself/himself to this problem, I'll investigate this 
further.

Running OOO 3.2.1m18 build 9502 - US english version. Set to use South Africa
language as default and I am experiencing he same issue. Reproducible everytime.
Tried removing profile and running in XP compatibility mode and it seems to
resolve the issue the first time I work on the document but when I reopen the
document the crash happens again.

Created attachment 71248 [details]
Backtrace of OOO320_m19, generated by WinDbg.

Created attachment 71249 [details]
Proposed patch to fix this problem. This patch was generated for OOO320_m19.

The root cause must be in vcl module according to the backtrace attached to this 
issue (i10981_backtrace_ooo320_m19.txt). This backtrace was displayed by WinDbg 
when Calc crashed in the reported way.

And I found that the modification, made in CWS graphite01, in 
vcl/win/source/gdi/winlayout.cxx caused this regression. The causal part of this 
file is commented out in the proposed patch. I confirmed Calc doesn't crash with 
this patch in Windows 7 + Microsoft IME 2007.

However, we may have to have the author of the causal part confirm this patch as 
I don't understand the intention behind that part.

@bluedwarf that code was originally added as a fix for i96925. Your patch
results in bad rendering of the file attached to that issue. Please can you try
to find out what the parameters are when those lines are called which cause the
crash. Is mpOutGlyphs being accessed out of range? Is font fallback involved
when the crash happens?

Unfortunately, my development machine is running Vista and I only have the
Microsoft IME, not the Microsoft Office IME 2007, so I can't reproduce your
crash to put a debugger on it.

I have Office 2010 installed as well. If I understand the problem correctly, it
is related to the MS Office IME, so would this problem go away if I uninstalled
MS Office? 

@kstribley sorry I misled you into a wrong discussion. Actually Calc crashes 
when the destructor of UniscribeLayout is called as you can see in the attached 
backtrace. In addition, today I found that the statement "delete [] 
mpLogClusters;" caused this crash. I guessed that some memories regarding 
mpLogClusters were freed twice, but I finally couldn't find the code which 
releases  mpLogClusters outside the destructor in winlayout.cxx.

So, next, I'll try tracing "delete" statements somehow, which I hope results in 
finding a root cause.

Please consider that the attached patch just shows that the modification made in 
graphite01 triggered this problem. I think the root cause should be around the 
modified part. But I would like you to remember what was changed in 
winlayout.cxx, and hopefully come up with a hint or solution of this problem. 
Please give me any comment or whatever you think. It will be very helpful.

(BTW, I don't understand the fallback system involving Uniscribe and Graphite 
engines.)

@mlpotgieter yes. However, the root cause seems to be in OOo itself, and we 
should fix it because it is very common to install MS-Office and OOo in one 
computer, especially in Japan.

Looking at the stacktrace more carefully, fallback fonts are involved, because
MultiSalLayout is present. You could try looking into MultiSalLayout and see if
you can find the problem font or the sequence of fallback fonts which it is
using. I would also try to identify the Unicode code points involved when the
crash happens. This might then enable the crash to be reproduced outside of that
dialog, and without use of the Office IME by explicitly typing those code points
and selecting the font which doesn't contain them. Perhaps the Office 
IME is causing a font to be set, which isn't otherwise, and which somehow
exposes a bug in the fallback code.

You can identify whether the problem is caused directly by Graphite rendering
code by setting the SAL_DISABLE_GRAPHITE=1 environment variable before you start
OpenOffice and seeing if the crash still occurs. However, when a Graphite font
is used, with SAL_DISABLE_GRAPHITE=0 or unset, then UniscribeLayout will not be
called at all for the Graphite font, GraphiteWinLayout will be used instead.
Microsoft fonts, won't have Graphite tables, but you may have Gentium Basic
installed.

Several fixes have been made to the OOo Graphite integration code (but not to
the UniscribeLayout class that you highlighted). If SAL_DISABLE_GRAPHITE makes a
difference, then it might be worth checking that the problem still exists on the
OOO330 code line.

reassign

set to confirmed (since there obviously are so many users who can reproduce this)

I tried setting the variable SAL_DISABLE_GRAPHITE=1 from the command line and
the problem did not go away.

Can anyone please tell the unenlightened how to install a "microsoft office ime"
? From the comments I got that I should get that with an installation of MSO,
however that does not seem to be so here ? Any specific sub package to install ?

First of all, I happened to know that this problem might be reproduced without 
Microsoft Office IME 2007. No matter what the default language is, OOO320_m19 
compiled with "--enable-dbgutil" configure option crashes on Windows 7. Could 
anyone try to reproduce this problem with that option? This might greatly help 
us speed up debugging because I can't afford to spare much time to this problem. 

@kstribley, thank you for your informative comments. I found that this crash 
happens when VCL tries to render Indian currency (INR) in Hindi. The fallback 
fonts set in mpFallbackFonts variable are following:

?? $!mpFallbackFonts[0]->maName
 => NULL
?? $!mpFallbackFonts[1]->maName
 => "Arial Unicode MS"

And, as you can see in the attached backtrace, Calc crashes when 
OutputDevice::GetTextArray called. One of the parameters (rStr) of this method 
shows what string VCL tried to render, which was following:

?? $!rStr->mpData->maStr
 =>
0x202a (LRE)
0x0049 'I'
0x004e 'N'
0x0052 'R'
0x202c (PDF)
0x0020 ' '
0x0020 ' '
0x202a (LRE)
0x0930 'र'
0x0941 ''
0x002e '.'
0x202c (PDF)
0x0020 ' '
0x0020 ' '
0x202a (LRE)
0x0048 'H'
0x0069 'i'
0x006e 'n'
0x0064 'd'
0x0069 'i'
0x202c (PDF)
0x0000 (NULL)

@mlpotgieter, thank you for your work. What if you install Gentium Basic fonts 
and set SAL_DISABLE_GRAPHITE=0?

@pl, Microsoft Office IME 2007 may probably bundled only with MS-Office 2007 
Japanese edition (and Korean Edition?). To check if it's installed, could you 
try the following steps on Windows 7?
1. Open "Region and Language" from Control Panels
2. Go to "Keyboards and Languages" tab
3. Click "Change Keyboards..." button to open "Text Services and Input 
Languages" dialog.
4. Click "Add" button to open "Add Input Language"
5. Check if "Japanese (Japan) - Keyboard - Microsoft Office IME 2007" is listed.
If not, MS Office IME 2007 is not installed. In that case, try to get MS Office 
2007 Japaense (or Korean?) package somehow. (I'm not sure if you can buy one 
outside Japan.)
c.f. http://www.wfu.edu/~yipcw/atg/ime/w7/

If SAL_DISABLE_GRAPHITE=0 doesn't make any difference, then I don't think this
has anything to do with Graphite fonts. i96925 was not directly graphite
related, but I originally added the i96925 patch to the graphite01 CWS because I
observed the bug while testing fallback between Graphite and OpenType fonts.

This may have something to do with the interrelation between font fallback and
the UniscribeLayout renderer, which is triggered by the currency symbols.
However, I don't understand how the IME would modify that process, so I still
think it is possible that the root cause lies elsewhere.

I am not a programmer so let me tell you how I tested so you can ensure what I
did was correct.
1. Downloaded and installed Gentium Basic fonts(installer found the font already
installed but I proceeded regardless.)
2. killed all soffice.bin processes and the quickstart tray process.
3. opened command prompt and entered "set SAL_DISABLE_GRAPHITE=1"
4. typed "set" at the command prompt to verify variable was set.
5. in the same command prompt, navigated to ooo programs directory and launched
soffice.exe
6. soffice launches and a blank Writer document is opened. I opened a new calc
spreadsheet from the Writer menu and entered numbers in a few cells. then right
clicked on a cell, selected format cell and then upon clicking on the numbers
tab, the program crashes after a few seconds.

I have tried setting SAL_DISABLE_GRAPHITE both to 1 and 0 and the program
crashes everytime in either case.

Also note that I only have English languages installed. I looked at
http://www.wfu.edu/~yipcw/atg/ime/w7/ and on the machine affected could not see
any mention of Microsoft IME. I certainly don't have a Chinese or Japanese
keyboard added.

@kstribley I found that the array index was negative when mpLogClusters was 
accessed in the following quoted line in winlayout.cxx.

>             mpLogClusters[ k ]    = static_cast<WORD>(nRelGlyphPos);

Although I'm not still sure why "k" could be negative, I confirmed we can solve 
this bug inserting the following line.

>        if ( k > 0 )
>             mpLogClusters[ k ]    = static_cast<WORD>(nRelGlyphPos);

Is this patch acceptable? Or could you investigate why it can be negative?

I would have thought k >=0 might make more sense:

>        if ( k >= 0 )
>             mpLogClusters[ k ]    = static_cast<WORD>(nRelGlyphPos);

Unfortunately, I'm still unable to reproduce this bug, so I can't easily
investigate why it is negative. It might be worth stepping through from at least
the GetItemSubrange call downwards. I wonder if it might in some way be related
to the Left to Right Embedding and Pop Directional Formatting codes, but that is
just a guess.

Great analysis, thanks! I'm having a deja vu moment (see issue 114245), which was
just fixed as suggested in CWS ooo33gsl08.
http://hg.services.openoffice.org/cws/ooo33gsl08/rev/5c31beadbd16
Please verify.

*** This issue has been marked as a duplicate of 114245 ***

Closing resolved issue.

This seems to happen after it has been open for a day.  Closing the program and
reopening seems to restore the ability to change tabs in Format to numbers for
awhile. Changing the profile has no effect.

*** Issue 115318 has been marked as a duplicate of this issue. ***