Am Samstag, 19. April 2014 schrieb Ian Wadham : > On 18/04/2014, at 4:58 AM, Thomas Lübking wrote:
>> If removing the KLocale() constructor avoids it, i'm fairly sure it will be the bogus CFStringGetLength call, so to me it would seem more reasonable to protect convert_CFString_to_QString >> >> kdelibs/kdecore/kernel/kkernel_mac.cpp >> ----------- >> >> QString convert_CFString_to_QString(CFStringRef str) { >> + if (str == NULL) { >> + return QString(); >> + } >> >> eventually print a warning (while i've no idea what this condition implies, like eg. a broken setup. It could be a bug in CFStringRef or CFLocaleGetValue or either isn't re-entrant or whatever) > > That is undoubtedly worth doing, but might not solve the whole problem. > See my reply to Luigi. Briefly, this is where the crash was in the only > backtrace we have ever had. There might be other crash-points. That will then expose and be fixable =) Of course altering the build script to not fail but write a "foobar.docbook.failed" warning (that ideally contains a coredump) would be a workaround to harden the process. (i've no insight into docbook creation - i google anyway ;-) >> And no, forking the application seems the worst option (remember Ian, you'd have to maintain that fork ;-) > > Not in my philosophy, Horatio … :-) > > Of course, if I made such a change I would take responsibility for it for as long as > I am able, but what then? I am getting rather old now … > > In my philosophy, also in the salaried part of the computer industry and FAIK in free > products like Firefox, maintenance is a *group* responsibility. Thanks for the lesson, but as German, let me be the Mephisto: That is certainly right. How many able mac developers are there in the group of interested people right now, again? >-) Cheers, Thomas
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<