[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-03-21 7:24:06
Message-ID: 435BC702-A7A1-485E-8EF1-60D8F4E7C847 () gmail ! com
[Download RAW message or body]

On 20/03/2014, at 7:28 AM, mk-lists@email.de wrote:
> On 19 Mar 2014, at 06:29 , Thomas L=FCbking <thomas.luebking@gmail.com> w=
rote:
>> There seems a known issue reg. multithreaded libxml2 [1], but since Mark=
o was the reporter, i simply ruled it out being the remaining one.
> =

> I doubt it was a libxml2 issue, since the corresponding poster wrote
> =97
> <p>Hi on windows we had a similar crash.</p>
> <div>The problem was in libxml2, when builded with multithread support.Di=
sabling multithread fixed it.</div>
> =97
> =

> The crash I described back then happened with KMyMoney, but did occur for=
 any other KDE software arbitrarily every now and then.
> =

> I think in order to reproduce the error I=92d also need to build stuff hi=
ghly parallel with all 8 cores and in an an endless loop, but I=92d need to=
 get familiar with parallel and stuff alike, I am afraid=85
> =

> Well, let=92s see what Ian can come up with once he=92s done with partyin=
g his birthday. ;-)

Heh!  Well, I am not any kind of KDE genius and kdoctools is foreign territ=
ory for me.
It's hard enough for me to write that .docbook format of documentation =85 =
:-)

I tried a little script to get meinproc4 to fail by executing several copie=
s in parallel.

    for game in killbots kjumpingcube konquest kpat kubrick kgoldrunner pal=
apeli
    do
        echo meinproc4 for $game
        cd /kdedev/games/$game/doc && /opt/local/bin/meinproc4 --check --ca=
che /kdedev/build/games/$game/doc/index.cache.bz2 /kdedev/games/$game/doc/i=
ndex.docbook &
    done

IOW, run meinproc4 for seven games Handbooks at once.  The main command is =
what
eventuates from CMake and make when you are installing documentation.  /ked=
dev
is my KDE development area and /opt/local/bin is where MacPorts puts utilit=
ies (though
not GUI applications, which require to be installed in a special way on Mac=
 OS X).

It was all over in a second or two, with a spike of about 1.5 cores on Appl=
e's
Activity Monitor.  No crashes.  But then meinproc4 never fails for me.

Then I wrapped a "do forever" loop around the above --- and then it crashed=
, but it was
hardly a fair test: writing seven output files an unknown number of times a=
t once.

So I think we can discount the concurrency-problem theory.

In any case, I had a look at
https://trac.macports.org/attachment/ticket/41326/main.log a huge log file =
(25Mb) from
a crash of meinproc4.  I do not know what this run was doing (there seems t=
o be no replay
of the MacPorts command that started it), but there seem to be multiple com=
mands that
are aimed at building meinproc4 itself.  What really happened?

Anyway, there is just one attempt to execute meinproc4, AFAICS, and that is=
 right near
the end of that huge log file.  So no concurrency.  Anyway, the one backtra=
ce we have
(not from this run BTW) shows meinproc4 failing on its one and only call to=
 KGlobal::locale();
at line 109 of file meinproc.cpp.  That is part of meinproc4's initialisati=
on, before it starts
processing any input.

That call to KGlobal::locale(); seems an odd one, KDE guys.  That function =
is supposed to
return a locale (KLocale *), but here it is executed as a procedure, ignori=
ng the return
result.  I can only conclude that the code is being executed for its side-e=
ffects, see:
http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/kglobal_8cpp_source=
.html#l00144

Macports guys, in https://trac.macports.org/attachment/ticket/41326/main.lo=
g,
meinproc4 is actually running inside a script called meinproc4.shell, which=
 I think may be
generated by MacPorts.

I wonder if meinproc4 has not been fully installed yet (it seems to be being
built earlier on in the run).  If so, I wonder if it is running from somewh=
ere that is not its
usual install location (i.e. not /opt/local/bin/meinproc4) or maybe it has =
been deprived
of its usual KDE environment setup in some way, so that is why it cannot fi=
nd a locale.

One final idea.  I see that there is a version of meinproc4 called meinproc=
4_simple,
which the KDE translators use for some purpose which I cannot quite make ou=
t.
Anyway, it appears to be a special-purpose version of meinproc4 and it is e=
ssentially
a Qt-only application.

I wonder if we could legislate the MacPorts meinproc4 bug out
of existence by making another special-purpose version of meinproc4 that on=
ly takes
in a .docbook file, checks it and spits out a .cache.bz2 file, thus omittin=
g the code where
meinproc4 appears to be crashing in the Apple OS X environment.  That versi=
on could
then be the one used to create Handbooks across all platforms.

Just a thought.

Cheers, Ian W.


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]