Community
Participate
Working Groups
Created attachment 284799 [details] Snippet Eclipse 4.18 Latest I build macOS 11.01 In Eclipse: 1. Open Preferences 2. Go to General -> Appearance -> Colors and Fonts 3. Select a color to change and click "Edit" to open a ColorDialog 4. Drag and drop the colored square in the bottem-left into one of the 16 slots 5. Eclipse will totally crash to desktop Attached is a snippet for testing purposes. 1. Run the snippet to open a ColorDialog 2. Drag and drop the colored square in the bottem-left into one of the 16 slots App will crash. Written to console: Assertion failed: (backingScaleFactor > 0.f), function drawnFocusRingBitmapForTime, file /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-2022.10.104/AppKit.subproj/NSAutomaticFocusRing.m, line 306.
Created attachment 284800 [details] Screenshot of Dialog Screenshot to show what I mean by "Drag and drop the colored square in the bottem-left into one of the 16 slots"
I can't count. Should be: "Drag and drop the colored square in the bottem-left into one of the *20* slots"
The Color Dialog works OK on native Mac apps in Big Sur, yet not in Eclipse/SWT. Is this because of linking to a particular version of Apple's libraries when creating the SWT binaries? I'm just curious.
Is anyone investigating yet?
I was able to crash macOS own applications the same way: 1) macOS | System Preferences | General | Highlight Colour Select 'Other' to open the color dialog. Drag&drop a color from bottom left to a slot in bottom right. 2) Notes | <right-click a note> | Font | Show colours Drag&drop a color from bottom left to a slot in bottom right. Some other applications, such as TextEdit, do not crash. After a color was moved in the slot, it needs to be deleted using Del key in order to reproduce crashes again. I conclude that this is a bug of macOS itself, which will hopefully be fixed soon.
Created attachment 284815 [details] Crash stack, as reported by macOS, of SWT
Created attachment 284816 [details] Crash stack of macOS own "Notes" app
I get the crash in "macOS | System Preferences | General | Highlight Colour" but not in the Notes app. macOS 11.0.1 (20B29) (You can also drag the color in the slot to the trash to remove it)
I think that it's not important why you don't get a crash in Notes. In any way it's a macOS bug.
(In reply to Alexandr Miloslavskiy from comment #5) > I was able to crash macOS own applications the same way: > 1) macOS | System Preferences | General | Highlight Colour > Select 'Other' to open the color dialog. > Drag&drop a color from bottom left to a slot in bottom right. > 2) Notes | <right-click a note> | Font | Show colours > Drag&drop a color from bottom left to a slot in bottom right. > > Some other applications, such as TextEdit, do not crash. > After a color was moved in the slot, it needs to be deleted using Del key in > order to reproduce crashes again. > > I conclude that this is a bug of macOS itself, which will hopefully be fixed > soon. Thanks for investigating, Alexandr.
Just had a customer report this to us in our product.. Do we know if Apple is aware of the bug? There's no public bug repo but perhaps there's some trace on the interwebs of someone having reported it already?
I can't reproduce the crash on macOS 11.3 Beta, followed steps from comment#0 and comment#5. Can someone please try it out and confirm?
I'm downloading 11.3 Beta 2 now, will take a little while..
I'm on 11.3 Beta (20E5186d) now. Unfortunately still getting the issue: - macOS | System Preferences | General | Highlight Colour -> "Preferences Error" - "There was an error in General preferences." and a crash report in Console.app - using ColorDialog via our application, dragging the colour as described, crashes the application, triggering a system problem report ".. quit unexpectedly" I've submitted a couple of reports via Apple's 'Feedback Assistant' application. Application Specific Information: Assertion failed: (backingScaleFactor > 0.f), function drawnFocusRingBitmapForTime, file /System/Volumes/Data/SWE/macOS/BuildRoots/a9f5d55ca2/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-2022.44.134/AppKit.subproj/NSAutomaticFocusRing.m, line 306. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff203e8936 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff20417615 pthread_kill + 263 2 libsystem_c.dylib 0x00007fff2036c411 abort + 120 3 libsystem_c.dylib 0x00007fff2036b7e8 __assert_rtn + 314 4 com.apple.AppKit 0x00007fff22ec3348 +[_NSAutomaticFocusRing showForView:forceRect:isAccessibilityRequest:] + 5255 5 com.apple.AppKit 0x00007fff236fe335 -[NSColorPanelFavoriteSwatch setSelected:] + 137 6 com.apple.UIFoundation 0x00007fff23b1015b __93-[_NSCollectionViewCore _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:]_block_invoke.800 + 95 7 com.apple.UIFoundation 0x00007fff23a53e37 +[_NSUIAnimator performWithoutAnimation:] + 87 8 com.apple.UIFoundation 0x00007fff23a533e7 -[_NSCollectionViewCore _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] + 1659 9 com.apple.UIFoundation 0x00007fff23a52cbf -[_NSCollectionViewCore dequeueReusableItemWithReuseIdentifier:forIndexPath:] + 72 10 com.apple.AppKit 0x00007fff22f11d16 -[NSCollectionView makeItemWithIdentifier:forIndexPath:] + 88 11 com.apple.AppKit 0x00007fff236ff0e3 -[NSColorPanelFavoritesList collectionView:itemForRepresentedObjectAtIndexPath:] + 50 :
(In reply to Justin Dolezy from comment #14) > I'm on 11.3 Beta (20E5186d) now. > > Unfortunately still getting the issue: > > - macOS | System Preferences | General | Highlight Colour -> "Preferences > Error" - "There was an error in General preferences." and a crash report in > Console.app > > - using ColorDialog via our application, dragging the colour as described, > crashes the application, triggering a system problem report ".. quit > unexpectedly" > > I've submitted a couple of reports via Apple's 'Feedback Assistant' > application. > Thanks for reporting this to Apple.
Still occurring on 11.3 Beta 3 (20E5196f) unfortunately..
I can't reproduce this problem in the system preferences of 11.2. Is this error machine dependent?
I can repro the problem in System Preferences on an 2017 iMac and a 2019 iMac. In my testing the conditions have to be right to trigger the issue this way - for example if the colour slots have an existing colour then adding a new one will not trigger it; they all have to be empty.. I've downloaded BS 11.3 beta 4 to the '17 iMac and I can still repro the problem :(
(In reply to Justin Dolezy from comment #18) > I can repro the problem in System Preferences on an 2017 iMac and a 2019 > iMac. In my testing the conditions have to be right to trigger the issue > this way - for example if the colour slots have an existing colour then > adding a new one will not trigger it; they all have to be empty.. > > I've downloaded BS 11.3 beta 4 to the '17 iMac and I can still repro the > problem :( Can confirm this is still happening in 11.2.3. As Justin says, if the color slots are all empty you're likely to get the crash. As a workaround I opened the TextEdit app and dragged and dropped a color to a slot. Then the crash doesn't occur thereafter, even if I empty all the slots. (I know this is still a macOS issue, not an Eclipse issue, just adding my 2 cents in case it helps someone)
It looks like this could well be resolved with Beta 6 - I had a quick go last night and couldn't replicate..
(In reply to Justin Dolezy from comment #20) > It looks like this could well be resolved with Beta 6 - I had a quick go > last night and couldn't replicate.. Tested with 11.3 (20E232) - unfortunately not fixed.
(In reply to Phil Beauvoir from comment #21) > (In reply to Justin Dolezy from comment #20) > > It looks like this could well be resolved with Beta 6 - I had a quick go > > last night and couldn't replicate.. > > Tested with 11.3 (20E232) - unfortunately not fixed. @Justin, could you please check if there was any update from Apple on the bug reports in Feedback Assistant?
No update from Apple on the report in Feedback Assistant, unfortunately.
I've updated to 11.5 (20G71) and can't reproduce this - anyone else fancy trying? Bug report in Feedback Assistant still marked as open..
(In reply to Justin Dolezy from comment #24) > I've updated to 11.5 (20G71) and can't reproduce this - anyone else fancy > trying? > > Bug report in Feedback Assistant still marked as open.. Same here on 11.5. Seems to be fixed.
(In reply to Phil Beauvoir from comment #25) > (In reply to Justin Dolezy from comment #24) > > I've updated to 11.5 (20G71) and can't reproduce this - anyone else fancy > > trying? > > > > Bug report in Feedback Assistant still marked as open.. > > Same here on 11.5. Seems to be fixed. Actually, not fixed on Mac M1 11.5.
Is this still a problem on latest macOS 11.6 or 12.1?
(In reply to Lakshmi P Shanmugam from comment #27) > Is this still a problem on latest macOS 11.6 or 12.1? Hi Lakshmi: I tested the instructions in comment #1 and comment #5 on: Eclipse 4.22 Mac M1 macOS 11.6.2 and, yes, it still crashes. I'll test in macOS 12.1 later.
(In reply to Phil Beauvoir from comment #28) > (In reply to Lakshmi P Shanmugam from comment #27) > > Is this still a problem on latest macOS 11.6 or 12.1? > > Hi Lakshmi: > > I tested the instructions in comment #1 and comment #5 on: > > Eclipse 4.22 > Mac M1 macOS 11.6.2 > > and, yes, it still crashes. > > I'll test in macOS 12.1 later. Tested on macOS 12.1 (Intel). Crashes as before.
I don't suppose you tried to repro the System Preferences case, Phil? If that's fixed then surely Apple have addressed it in Sys Prefs code and not in the underlying API, implying this one isn't going to get fixed 'by itself' in an OS update..? I've checked the Feedback Assistant report I submitted last Feb and no update/repsonse at all I'm afraid.
(In reply to Justin Dolezy from comment #30) > I don't suppose you tried to repro the System Preferences case, Phil? > > If that's fixed then surely Apple have addressed it in Sys Prefs code and > not in the underlying API, implying this one isn't going to get fixed 'by > itself' in an OS update..? > > I've checked the Feedback Assistant report I submitted last Feb and no > update/repsonse at all I'm afraid. Yes, tried that too. Still crashing.
But, yes, this is clearly not an Eclipse bug but an Apple one. We could close this as "NOT_ECLIPSE" if folks want?
I'm on macOS 12.1 on a Mac min (M1, 2020) and when I open System Preferences > Desktop & Screen Saver > Desktop > Apple > Colours, click Custom Colour and drag a color from the larger rectangle in the lower left corner to one of the slots right beside it, it works fine.
Even when doing the same in the Colors dialog launched from SmartGit, it works without a crash.
(In reply to Thomas Singer from comment #34) > Even when doing the same in the Colors dialog launched from SmartGit, it > works without a crash. Actually I can make it crash even on SmartGit with macOS 12.1. It does depend on some conditions as mentioned in Comment #18.
SmartGit is an RCP/SWT app isn't it? In which case it also crashing doesn't really prove anything, right?! I've seen posts on Adobe forums about this crash in some of their products (they were using SWT at some point, but not now?) and there have been replies that they've fixed the issue, without any further details unfortunately. So it would seem there's some way to prevent this. I've just posted about this to the Apple Developer forums (only just discovered that).. - https://developer.apple.com/forums/thread/698675 I've mentioned there about some detail someone else included in another post re Xamarin, where someone has produced a snippet in Objective-C that demonstrates the problem also.. - https://github.com/xamarin/xamarin-macios/issues/9484
(In reply to Justin Dolezy from comment #36) > I've mentioned there about some detail someone else included in another post > re Xamarin, where someone has produced a snippet in Objective-C that > demonstrates the problem also.. > > - https://github.com/xamarin/xamarin-macios/issues/9484 @Justin, Thanks for the link! From the post, "This issue only occurs when /Users//Library/Colors/NSColorPanelSwatches.plist doesn’t exist. If file is there already, sample code works well." I checked on my machine, this plist file does exist. I tried removing it and running the snippet, but it gets created again after picking the color. Can you pls check if this file exists on the machine where this crash occurs? May be copying the file from another machine could fix it?
Lakshmi, I can make Eclipse and SWT/RCP apps crash even if the plist file is there. The main thing is that the slots in the Color dialog are empty.
@Phil, you've repro'd this on both Intel & M1 yes? I've been having trouble replicating on an Intel iMac for a while. It's currently on 12.2 Beta 21D5039d. Wanted to do a LICEcap screen recording of the Sys Prefs crash but I can't trigger it at the moment - I seem to have lost the knack!
(In reply to Justin Dolezy from comment #39) > @Phil, you've repro'd this on both Intel & M1 yes? > > I've been having trouble replicating on an Intel iMac for a while. It's > currently on 12.2 Beta 21D5039d. Wanted to do a LICEcap screen recording of > the Sys Prefs crash but I can't trigger it at the moment - I seem to have > lost the knack! Yes, on Intel and M1. But in M1 12.1 it doesn't crash in macOS apps like Preferences and Notes, only Eclipse, our app Archi and SmartGit (i.e SWT/RCP)
I had the same issue with a crash in the Color dialog of macOS with our application. When searching in the internet I found this Eclipse bug report which made me much more confidet, that the crash is a bug in macOS. Especially the link to Xamarin where there could be found a simple native objective-C test program where the crash can be reproduced. It seems that Apple has meanwhile fixed that issue. With the latest updates macOS Ventura 13.6.6 and macOS Sonoma 14.4.1 I could no longer reproduce the crash. Probably it was already fixed in some earlier version of Ventura and Sonoma, I did not check each macOS update of the last months. I could still reproduce the issue with macOS 12.7.4 and macOS 11.7.10, so it seems Apple has fixed the issue just for the "current" macOS version Ventura and Sonoma, but not for the "older" versions Monterey and Big Sur.
