Issue 27492 - Font engine corruption and incompatibility with Delphi
Summary: Font engine corruption and incompatibility with Delphi
Status: CLOSED DUPLICATE of issue 21114
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC Windows 98
: P3 Trivial (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@gsl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-06 10:39 UTC by freemant
Modified: 2004-04-08 14:59 UTC (History)
2 users (show)

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


Attachments
Stack trace when inserting a graphics into Writer (while Delphi is open) (209.96 KB, text/txt)
2004-04-08 05:40 UTC, freemant
no flags Details
Crash again when resizing a graphics (209.39 KB, text/txt)
2004-04-08 05:51 UTC, freemant
no flags Details
Crash again when resizing a graphics to its original size (209.39 KB, text/txt)
2004-04-08 05:53 UTC, freemant
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description freemant 2004-04-06 10:39:19 UTC
If I have Impress or Writer running for a while, frequently it will become
unable to use the correct font. Instead, it uses some kind of system font (I
suspect) and thus everything looks odd. In fact, sometimes it makes other
running applications (eg, Mozilla) unable to get their fonts too. So it seems to
corrupt the font engine in Windows.

This issue can be triggered easily by running Delphi (I use Delphi 7 enterprise)
and OOo at the same time. OOo can easily trigger errors like "Incorrect
parameter" or "Unable to draw" when I switch to Delphi. With Delphi's presence,
OOo can also easily crash, particularly when I insert a graphic (by pasting).
Before it dies, it will always display the document's text in a special font
first, followed by a system message box saying something like "Application has
caused an unrecoverable error".

I am using the Chinese version (big5) of Win98 second edition. I am using the
Unicode layer installed by OOo's setup program.
Comment 1 christof.pintaske 2004-04-07 11:20:52 UTC
cp->freemant: please try the 1.1.1, please send an error report (stack trace)
when the office crashes.
cp->sba: this may or may not have something to do with internal #112304#.
However I have no chance to test this. Can you test on Win98 Chin ? or push this
to China ? 
Comment 2 freemant 2004-04-07 11:45:05 UTC
Thanks for the reply. I'll try 1.1.1.

Regarding the stack track, how to generate it?
Comment 3 freemant 2004-04-07 12:02:12 UTC
Just tried 1.1.1. It is still the same. I can crash it in a few trials (with
Delphi opened). When it dies, it displays a error report window. Is clicking the
"error report" button supposed to show the stack trace? I tried but it opens a
window with nothing in it (no text).
Comment 4 freemant 2004-04-07 12:14:28 UTC
Wait. After rebooting the computer, it seems that 1.1.1 is working without this
problem. I'll continue to test it. Thanks!
Comment 5 christof.pintaske 2004-04-07 12:44:04 UTC
yep, please try to send the error report, press "Enter" key several times if it
is empty. At least I hope that it works
Comment 6 freemant 2004-04-08 05:38:49 UTC
It happens again even with OOo 1.1.1. Please find the stack trace attached.
Comment 7 freemant 2004-04-08 05:40:35 UTC
Created attachment 14402 [details]
Stack trace when inserting a graphics into Writer (while Delphi is open)
Comment 8 freemant 2004-04-08 05:51:46 UTC
Created attachment 14403 [details]
Crash again when resizing a graphics
Comment 9 freemant 2004-04-08 05:53:54 UTC
Created attachment 14404 [details]
Crash again when resizing a graphics to its original size
Comment 10 stephan_schaefer 2004-04-08 11:55:13 UTC
I had a look at the stacktrace and could see that OOo was unable to create a
window. Because the description mentions font problems too and the system is
Windows98, it seems that the system resources are exhausted, either due to OOo
or due to any other process that is running simultaneously.

So I woud suggest tracking down which process causes those problems using a
resource meter.
You can for example download such a tool from
http://www.techadvice.com/w98/R/Resource_Meter.htm and check if the resources
are going dramatically down during the use of OOo. It would especially be useful
to see if all resources reach the level they had before starting OOo after you
close it.
Then do the same with delphi. 

If both applications behave well, it may be that the sum of both applications
together consumes too much resources, in which case you would have to restrict
yourself to only one of them at a time... 


Comment 11 freemant 2004-04-08 14:08:54 UTC
Thanks for the tip. Experiements:
1. Neither OOo nor Delphi is open. System (and GDI) resources: 70% free.
2. OOo is open alone. System (and GDI) resources: 63% free.
3. OOo is open and a complex document containg graphics is loaded. System (and
GDI) resources: 63% free (yes, no change at all).
4. Insert a new graphics (screenshot) into an empty document. System (and GDI)
resources: 31% free. Why this significant change? Quitting OOo restores to 70%
free. Inserting another graphics do NOT change the resources used.
5. Delphi is open alone. System (and GDI) resources: 45% free.
6. OOo (empty doc) and Delphi are both open. System (and GDI) resources: 39%
free. It is obvious that if now I insert a graphics, about 32% will be gone.
This would leave only 7% free. That's why the apps can crash easily at this state.

So, I guess the question is why the first insertion of a graphics takes so much
resources?
Comment 12 stephan_schaefer 2004-04-08 14:58:28 UTC
The resource problem is fixed with Issue 21114. The fix will be in OOo2.0 and is
already available in the developer builds (which of course still have pre-alpha
status, so actually using them is not recommended).


*** This issue has been marked as a duplicate of 21114 ***
Comment 13 stephan_schaefer 2004-04-08 14:59:09 UTC
closing