[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-04-19 6:16:30
Message-ID: 5DA2DC2B-F174-47F5-BDE1-68A62E43D62F () gmail ! com
[Download RAW message or body]

On 18/04/2014, at 4:58 AM, Thomas Lübking wrote:
> On Donnerstag, 17. April 2014 20:32:17 CEST, Luigi Toscano wrote:
> > Ian Wadham ha scritto:
> > 
> > > Sorry it has been such a while since you wrote.  A lot of water has
> > > flowed under the bridge since then, but this issue is still of the utmost
> > > importance to MacPorts.  See:
> > > https://trac.macports.org/wiki/KDEProblems/KDETickets ...
> > 
> > Thanks for looking into it, just to question here:
> > - did you try to just disable that line? It's certainly less "breaking" than
> > try to rewrite a tool where locale support have been rewritten in KF5.
> 
> 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) 
> And no, forking the application seems the worst option

Okay, so how about the following idea?

meinproc4 is essentially what, back in the day, we used to call a batch
process.  It runs with no GUI and without interaction, often as part of a
larger batch process, such as a MacPorts build.  It should not crash,
taking everything else with it, but should fail gracefully.  The worst
that should happen is that one KDE Handbook does not get built.

This is much better than having *no* KDE Handbooks built, which has
been the default in MacPorts for a few years now, because of the risk
of meinproc4 crashes.

So, can we add a signal trap to meinproc4, so that it issues a heavy
warning message, but then exits normally, leaving the rest of the run
to continue?  Or can the kde4_create_handbook() macro be modified,
so that if meinproc4 crashes we automatically produce debugging
info and just carry on?

There must be ways to do this within KDE or Qt or C++ even.

All the best, Ian W.


> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]