In the objc_msgSendSuper case, it actually appears to have been caused from a Dialog Open which in turn comes from the ‘choose workspace’ dialog.
So at this point, if the user takes more than a couple of seconds to choose what value to put in there, you’ll see a stack trace like this. It’s not really a bug in SWT; it’s the fact that there’s a modal ‘choose directory dialog’ for the workspace, and arguably you can’t really do much in Eclipse before you’ve done that (which is why it’s blocking).
I suspect in this case the real issue is that the ui monitoring is monitoring before the workspace is even open. Ideally you’d want to wait until after that dialog has been shown before triggering. Not sure if it’s possible to discount stack traces containing the following, but I suspect it will be the same on other windowing systems as well.
Alex Hi SWT collegues,
in platform UI we get UI freezes reported with is triggered by org.eclipse.swt.internal.*.OS. See below for the details.
Is this something useful for SWT development or should we filter such stack traces?
Best regards, Lars
_______________________________________________ platform-swt-dev mailing list platform-swt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
|