Bug 156254

Summary: Race condition: opening same document doesn't always give same fonts
Product: [Fedora] Fedora Reporter: Hans de Goede <hdegoede>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ilya.konstantinov, paul, uraeus
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-28 17:13:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
document showing the described behaviour
none
screenshot of wrong rendering
none
screenshot of right rendering none

Description Hans de Goede 2005-04-28 14:07:02 UTC
I've seen this bug in 1.9.91, 1.9.92 and now in 1.9.96. I wanted to reported it
earlier but ....

The problem with 1.9.91 and 1.9.92 was that if I opened a document (be it doc,
sxw or odt) the first time that I opened it the pagebreaks would be completly
wrong, because text which used to fit on a page now was sligthly to large.
Closing the document without saving and reopening it immediatly fixed this.

With 1.9.96 the problem is that the first open the onscreen rendering cleary
uses a wrong font, which also results in missing bullets. See attached
screenshot wrong.png. The second open is fine (just as with 1.9.91 & 1.9.92),
see correct.png .

I already thought this was a timing / race thing but now with 1.9.96 I'm pretty
sure. With 1.9.96 I get the wrong version just about a s often as I get the
right version. Closing oo then starting firefox and after firefox restarting oo
is a sure way to get it. Then closing oo and immediatly restarting it fixes it.
closing oo and then doing some browsing (firefox was still open) and then
restarting oo sometimes gets me the wrong version.

Appereantly if oo is very hot in the file cache the timing is ok and things go
ok, otherwise they go wrong.

It looks to me like some thread is still building/modifying the fonttable when
the document reading thread starts using it.

I've also seen simular behaviour opening a presentation (be it ppt, sxi, or ods)
sometimes the text would go beyond the bottom of a slide and after just a simple
restart of oo it would be fine. I've even had a  case where I accidently opened
the same presentation twice and the first instance of the text didn't fit the
slides and the second one it did.

I hope thats enough info. I'm reporting this and a couple of other bugs here and
not upstream because:
-FC version contains many mods I dunno if upstream is gonna be happy with FC ooo
 reports.
-ooo's bug tracker needs a manual: I tried to look for similar bugs on ooo but
 I didn't make it through the query page to many components and options, dunno
 what checkboxes to check, etc.

Comment 1 Hans de Goede 2005-04-28 14:07:03 UTC
Created attachment 113780 [details]
document showing the described behaviour

Comment 2 Hans de Goede 2005-04-28 14:08:05 UTC
Created attachment 113781 [details]
screenshot of wrong rendering

Comment 3 Hans de Goede 2005-04-28 14:08:41 UTC
Created attachment 113782 [details]
screenshot of right rendering

Comment 4 Caolan McNamara 2005-04-28 14:49:42 UTC
very strange sounding problem. I can't reproduce it yet, but I believe you :-)

Comment 5 Hans de Goede 2005-04-28 14:52:23 UTC
I already was afraid that you wouldnot be able to reproduce it :|

Maybe this helps: I just noticed that not only the document fonts but also the
menu and other UI elements including dialogboxes fonts change, see the menus in
the screenshots.


Comment 6 Hans de Goede 2005-04-28 15:02:13 UTC
Another fun observation while trying to create a reproducable case of another
problem. With 1.9.96 it seems that every even numbered start goes ok, I'm seeing
the following pattern (each instance is fully closed before starting the next):
-start oowriter -> wrong
-start oowriter -> ok
-start oowriter -> wrong
-start oowriter -> ok
-start oowriter -> wrong
-start oowriter -> ok
-start oowriter -> wrong
-start oowriter -> ok

Etc. font-cache locking issue? This is with a fully updated rawhide system. (yum
upgraded from FC3 at the time of FC4-test1)


Comment 7 Hans de Goede 2005-04-28 16:13:25 UTC
I'm seeing the exact same alternating wrong fonts right font behaviour with
impress now. Digging deeper...


Comment 8 Hans de Goede 2005-04-28 17:13:19 UTC
Hmm, I thought that this was kinda like a cache filelocking issue so I thought
where o where does ooo store things like this. As usual during the coffeebreak I
had an insight, the .openoffice.org2.0 dir in my homedir so I renamed this with
.bak as extra extension and problem gone.

I've done a diff between the bak and the new dir, but in the xml files there
where no changes which could explain this. Well thats what you get running beta
software :)

Closing.

Starting ooo now is pretty slow all of a sudden and during start it gives:
javaldx: Could not find a Java Runtime Environment!

Any clues?


Comment 9 Caolan McNamara 2005-04-29 07:21:31 UTC
the .openoffice.org2.0 dir causing something like this is weird. The javaldx:
"Could not find a Java Runtime Environment" should go away if libgcj is
installed, OOo should require this to pull in the gcj as java replacement stuff

Comment 10 Caolan McNamara 2005-04-29 14:05:01 UTC
This problem is almost certainly
http://qa.openoffice.org/issues/show_bug.cgi?id=45298. See the "even/odd"
similarity and the fontcache sizes.

Comment 11 Hans de Goede 2005-05-09 11:35:08 UTC
I still get: javaldx:
"Could not find a Java Runtime Environment"

This causes quite a long startup delay which is kinda annoying, note I do have a
"real" jdk and its bin dit is in my path.

New bug?


Comment 12 Hans de Goede 2005-05-09 11:35:33 UTC
s/dit/dir


Comment 13 Caolan McNamara 2005-05-30 09:12:25 UTC
*** Bug 157817 has been marked as a duplicate of this bug. ***

Comment 14 Caolan McNamara 2005-06-17 08:06:19 UTC
*** Bug 160689 has been marked as a duplicate of this bug. ***

Comment 15 Ilya Konstantinov 2005-06-22 22:55:30 UTC
How come this is NOTABUG in the light of OO.org QA issue 45298?