Issue 97423 - high cpu load with system file gtk dialog
Summary: high cpu load with system file gtk dialog
Status: CLOSED DUPLICATE of issue 93366
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOO300m9
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: caolanm
QA Contact: issues@gsl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-19 09:33 UTC by andyrtr
Modified: 2009-01-05 12:44 UTC (History)
1 user (show)

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


Attachments
the workspace as a patch (9.74 KB, patch)
2008-12-19 12:41 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description andyrtr 2008-12-19 09:33:37 UTC
Our ArchLinux packages show 100% cpu load (one core) when using system file
dialog. The internal file dialog works well.

It happens when using "open file" or "save as" and the gtk file dialog is shown.
Closing the dialog makes the cpu work normal again. We build with system libs
and use glib2 2.18.3 / gtk2 2.14.5.

It happens in the stable OOO300 tree and also in DEV300_m37. We only use the
go-oo default-system-fpicker.diff to use system fpicker by default and preset
gnome vcl to workaround some system glib issue.
Comment 1 jsc 2008-12-19 09:55:10 UTC
do you have tried it without the go-oo diff?

Anyway please contact the go-oo guys for help  
Comment 2 caolanm 2008-12-19 10:49:32 UTC
Well, this would be a gtk fpicker issue rather than an API, so probably belongs
logged against me.

But in workspace fpicker8 we removed the thread that was causing a 100% load
that sounds just like this so it is strange to hear that it is seen in
DEV300_m37. Are you sure it is visible in a devel version ?
Comment 3 andyrtr 2008-12-19 12:21:13 UTC
ups. last snapshot we have is DEV300_m35. I hope I can confirm the fix in m38
(m37 doesn't build here).

Does OOO300_m14 have it fixed?
Comment 4 caolanm 2008-12-19 12:41:21 UTC
Created attachment 58937 [details]
the workspace as a patch
Comment 5 caolanm 2008-12-19 12:44:33 UTC
No, m9 doesn't have the fix, but attached here is the workspace which should
apply against OOO300_m9.

EIS tells me that this was integrated in DEV300_m33 so if we're talking about
the same problem then I wouldn't expect to see it in >= m33
Comment 6 andyrtr 2008-12-20 16:40:16 UTC
together with the patch from #93366 it's solved here.
Comment 7 caolanm 2008-12-23 12:27:46 UTC
Ah yes, got a little confused it was cmcfixes50 wasn't it, not fpicker8. Two
different workspaces around fpickers at the time.

So this is ok then right ?, i.e. fixed with 93366

*** This issue has been marked as a duplicate of 93366 ***
Comment 8 caolanm 2009-01-05 12:44:31 UTC
closing as dup