Jim Walker wrote:
> Thanks Brian,
>
> Was there a flag day for this? If not, I would think about
> making one. Finding the bugs is a good thing, but impacting
> users that don't have time to be beta testers at the moment
> isn't.
I'll ask the RE team about this.
>
> I'm focused on testing myself, so understand both view points.
Yes there was also quite a debate over this in the GNOME community.
>
> My system is still crashing after applying the workarounds.
> Is there a way to disable bug buddy/coreing on ASSERT on
> a live system?
Unfortunately, no.
>
> Thanks,
> Jim
>
> Brian Nitz wrote:
>> A few things happened to make crashes more common in recent GNOME
>> builds:
>>
>> 1) The GNOME community enabled coreing on ASSERTs in default builds,
>> so some subtle bugs became less subtle.
>> 2) Coring on ASSERT causes some post install scripts to fail on some
>> hardware due to a file access race condition. Here are two bugs
>> related to that and the corresponding workarounds:
>>
>> 6631419 - gtk-update-icon-cache dies on first boot after install/upgrade
>> Workaround: (as root)
>>
>> for d in /usr/share/icons/*; do
>> [ -d $d ] &&
>> gtk-update-icon-cache --force $d;
>> done
>>
>>
>> 6578750 - fontconfig crash in FcPatternPosition. This should be
>> fixed in snv_85:
>>
>> Run "/usr/bin/fc-cache -sv" from the console, or a failsafe session
>> as yourself and as root.
>>
