Home » Eclipse Projects » Subversive » 3.4 (Mac) very slow to show right-click (context) menu - SVN* present in call trace
| 3.4 (Mac) very slow to show right-click (context) menu - SVN* present in call trace [message #23292] |
Wed, 02 July 2008 11:49  |
 John Hawksley
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Hi e.t.subversive:
I'm reposting this in here as well as e.platform, in case anyone sees
this too and might have a solution. All plugins are up to date, also
using the weeky-site. The presence of an SVN* call in the o/s thread
stack is strange because I though the SVNKit package did not use a
native dyld library. Of course this might be something else entirely
and I've misinterpreted it.
Both CPU cores become about 80% busy when this occurs.
-J
-- Original message --
Hi guys,
I wondered if anyone else is seeing this. I couldn't find a bug about it.
I'm on OS X 10.5.4 (Intel), with latest updates.
When I right click on a Java source file in the Package Explorer, 4
times in 5, Eclipse performance will degrade to the mac beach ball
(which I believe means that the app is no longer servicing its GUI event
queue), for about 10 seconds. After the application returns, it cannot
be raised using alt-tab, its icon must be clicked to raise it.
I'll attach the OS call stack at the end of this message. It mentions
SVN*, so I suspected some native SVN library, but I'm using SVNKit 1.2.0
with Subversive.
Best regards,
-John
653 Thread_2503
653 start
653 _start
653 main
653 original_main
653 run
653 startJavaVM
653 startJavaJNI
653 JNI_CreateJavaVM_Impl
653 0x110a368c
653 0x11119356
653 0x1111963a
653 0x139e8227
653 0x139ea9d3
653 0x139ea9d3
653 0x139eaaaa
653 0x139eadb0
653 0x139eaaaa
653 0x139eaaaa
653 0x139f09b1
653 JVM_InvokeMethod
653 0x110d7e4f
653 0x110bb4b1
653 0x11119356
653 0x1111963a
653 0x139e8227
653 0x139eaaaa
653 0x139eaaaa
653 0x139eaaaa
653 0x139eadb0
653 0x139eadb0
653 0x139eaa7f
653 0x139eaa7f
653 0x139ea9d3
653 0x139eacd9
653 0x139eaa7f
653 0x139eaa7f
653 0x139ea9d3
653 0x13a63b00
653 0x1429a86c
653 0x14521dcc
653 0x142b4b11
653 Java_org_eclipse_swt_internal_carbon_OS_SendEventToEventTarg et
653 SendEventToEventTarget
653 SendEventToEventTargetInternal(OpaqueEventRef*,
OpaqueEventTargetRef*, HandlerCallRec*)
653 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*)
653 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*)
653 SendEventToEventTarget
653 SendEventToEventTargetInternal(OpaqueEventRef*,
OpaqueEventTargetRef*, HandlerCallRec*)
653 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*)
653 0x34a458
653 callback
653 JNI_CreateJavaVM_Impl
653 0x110a368c
653 0x11119356
653 0x1111963a
653 0x139e8227
653 0x139eaa7f
653 0x13a5cdc0
653 0x145321a0
653 0x139eaa7f
653 0x139f09b1
653 Java_org_eclipse_swt_internal_carbon_OS_CallNextEventHandler
653 CallNextEventHandler
653 SendEventToEventTargetInternal(OpaqueEventRef*,
OpaqueEventTargetRef*, HandlerCallRec*)
653 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*)
653 StandardWindowEventHandler(OpaqueEventHandlerCallRef*,
OpaqueEventRef*, void*)
653 HandleMouseEvent(OpaqueEventHandlerCallRef*, OpaqueEventRef*)
653 HandleWindowClick(OpaqueWindowPtr*, Point, short, unsigned long,
OpaqueEventRef*)
653 HandleClickAsHIView(OpaqueWindowPtr*, OpaqueEventRef*)
653 HIView::Click(OpaqueEventRef*)
653 SendEventToEventTarget
653 SendEventToEventTargetInternal(OpaqueEventRef*,
OpaqueEventTargetRef*, HandlerCallRec*)
653 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*)
653 HIView::EventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
653 HIView::ClickSelf(OpaqueEventRef*)
653 HIView::ClickInternal(CGPoint const&, unsigned long, void
(*)(OpaqueControlRef*, short), OpaqueEventRef*, bool)
653 SendControlDefTrack(HIView*, CGPoint const&, unsigned long*, void
(*)(OpaqueControlRef*, short), OpaqueEventRef*, short*)
653 SendEventToEventTargetWithOptions
653 SendEventToEventTargetInternal(OpaqueEventRef*,
OpaqueEventTargetRef*, HandlerCallRec*)
653 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*)
653 0x34a198
653 callback
653 JNI_CreateJavaVM_Impl
653 0x110a368c
653 0x11119356
653 0x1111963a
653 0x139e8227
653 0x13a5cdc0
653 0x13ac1e04
653 0x13e18ab8
653 0x139eab2b
653 0x13a5cdc0
653 0x1452178c
653 0x139eaa7f
653 0x139f09b1
653 Java_org_eclipse_swt_internal_carbon_OS_ContextualMenuSelect
653 ContextualMenuSelect
653 _ContextualMenuInsertItems(MenuData*, unsigned short, AEDesc const*,
ContextualMenuHelp const*, unsigned long*, OpaqueContextualMenuItemsRef**)
653 TContextualMenuPluginList::ExamineContext(AEDesc const*,
TPluginCommandList&, long)
653 TContextualMenuPlugin::ExamineContext(AEDesc const*,
TPluginCommandList&, unsigned long, unsigned char&)
653 SVNPluginExamineContext
609 SVNPluginExamineContextDoAE
400 AEGetNthDesc
279 AEGetNthDesc
121 getDescDataType(AEDesc const*)
121 getDescDataType(AEDesc const*)
209 SVNPluginExamineContextDoAE
44 dyld_stub_AEGetNthDesc
44 dyld_stub_AEGetNthDesc
|
|
|
| Re: 3.4 (Mac) very slow to show right-click (context) menu - SVN* present in call trace [message #23333 is a reply to message #23292] |
Wed, 02 July 2008 12:39  |
Eclipse User |
|
|
|
Originally posted by: alexander.gurov.polarion.org
Hello John,
I'm not sure what is the "SVN" which is pointed by this stack trace
because Subversive plug-in does not contain entities named
SVNPluginExamineContext or SVNPluginExamineContextDoAE.
Also if you works with a very large projects please ensure that option
"Window->Preferences->Team->SVN->Performance->Calculate precise Team Menu
enablements" is unchecked (its default state).
|
|
| | |
| Re: 3.4 (Mac) very slow to show right-click (context) menu - SVN* present in call trace [message #23710 is a reply to message #23627] |
Wed, 02 July 2008 14:11 |
John Hawksley
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Hi folks,
Okay I've just come up to speed on Mac Contextual Menu plugins, and have
found the culprit. A beta application called "dropbox" (which
performs folder syncing) installed a context menu plugin, the removal of
which made this problem go away. I'll report this to them.
@Alexander: thanks for your time.
-John
John Hawksley wrote:
> Just for info, I used the jstack tool and here's where main is stuck,
> looks like an SWT-Carbon bug:
>
> "main" prio=6 tid=0x11401560 nid=0xa0588fa0 runnable
> [0xbfffd000..0xbffff668]
> at org.eclipse.swt.internal.carbon.OS.ContextualMenuSelect(Nati ve
> Method)
> at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:232)
> at org.eclipse.swt.widgets.Display.runPopups(Display.java:3526)
> at
> org.eclipse.swt.widgets.Control.kEventControlTrack(Control.j ava:2083)
> at org.eclipse.swt.widgets.Widget.controlProc(Widget.java:375)
> at org.eclipse.swt.widgets.Display.controlProc(Display.java:862 )
> at org.eclipse.swt.internal.carbon.OS.SendEventToEventTarget(Na tive
> Method)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3047)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2382)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 98)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:488)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:113)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:382)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
>
>
> John Hawksley wrote:
>> Hi Alexander,
>>
>> Thanks very much for having a look at this for me. Those trace
>> elements confuse me too - I wouldn't expect to see anything Java
>> related in an o/s trace (except where native code was used). I
>> googled them and nothing came back, so I don't have any clue where
>> they are coming from.
>>
>> We are working with large projects, and I had already disabled that
>> checkbox, with no effect.
>>
>>
>> -John
>>
>>
>> Alexander Gurov wrote:
>>> Hello John,
>>>
>>> I'm not sure what is the "SVN" which is pointed by this stack trace
>>> because Subversive plug-in does not contain entities named
>>> SVNPluginExamineContext or SVNPluginExamineContextDoAE.
>>>
>>> Also if you works with a very large projects please ensure that
>>> option "Window->Preferences->Team->SVN->Performance->Calculate
>>> precise Team Menu enablements" is unchecked (its default state).
>>>
>>>
|
|
| | | |
| Re: 3.4 (Mac) very slow to show right-click (context) menu - SVN* present in call trace [message #24533 is a reply to message #24492] |
Sun, 06 July 2008 17:56 |
John Hawksley
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Hi Werner,
Well in my case, the problem was that the Dropbox software (nothing to
do with Eclipse) had attached itself to all Mac context menus, and was
causing the problem. The Dropbox team fixed their software with the
next build and now all is well.
It actually was nothing to do with SVN at all, in fact it affected other
Mac applications, not just eclipse.
As I said, if you are having a specific problem with SVN sync, I'm sure
Alexander or the other Polarion guys will be pleased to help you sort it
out, just that this single issue in my case came down to something else
I had installed on my mac, not Eclipse.
Cheers,
-John
Werner Keil wrote:
> You say, it's just a GUI widget problem?
> Nevertheless I have whitnessed quite similar issues when right-clicking
> on e.g. a project. I would not say it is only related to SVN-sync, that
> is just one of the actions I tend to use more often.
>
> Gruss aus Berlin (but I probably get down to the Karlsruhe area next
> week ;-)
> Werner
>
> John Hawksley wrote:
>> Hi Werner,
>>
>> I have had a conversation with the DropBox team with respect to this
>> issue, and they report that several Mac apps were affected, not just
>> Eclipse. They pushed a new build (0.6.284) out which completely
>> resolves the issue.
>>
>> I'm afraid I can't help your SVN sync issues, I would suggest maybe
>> starting a new thread in this group, and maybe Alexander can offer
>> some words of wisdom.
>>
>> Schoene Gruesse aus Boeblingen/Stuttgart,
>> -John
>>
>>
>> Werner Keil wrote:
>>> Will this be fixed in Subersive only or does it affect larger parts
>>> of Eclipse or at least Ganymede?
>>>
>>> I too have seen very bad response times and Eclipse often hanging for
>>> minutes if I right click or try to use SVN Sync. And that's not just
>>> because I still got a Mac Mini with only 500 MB ;-)
|
|
|
Goto Forum:
Current Time: Fri Apr 19 22:39:42 GMT 2024
Powered by FUDForum. Page generated in 0.04443 seconds |
] 
Search
Help
Register
Login
Home
