On 20/03/2014, at 7:28 AM, mk-li...@email.de wrote:
> On 19 Mar 2014, at 06:29 , Thomas Lübking <thomas.luebk...@gmail.com> wrote:
>> There seems a known issue reg. multithreaded libxml2 [1], but since Marko
>> was the reporter, i simply ruled it out being the remaining one.
>
> I doubt it was a libxml2 issue, since the corresponding poster wrote
> —
> <p>Hi on windows we had a similar crash.</p>
> <div>The problem was in libxml2, when builded with multithread
> support.Disabling multithread fixed it.</div>
> —
>
> 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’d also need to build stuff highly
> parallel with all 8 cores and in an an endless loop, but I’d need to get
> familiar with parallel and stuff alike, I am afraid…
>
> Well, let’s see what Ian can come up with once he’s done with partying his
> birthday. ;-)
Heh! Well, I am not any kind of KDE genius and kdoctools is foreign territory
for me.
It's hard enough for me to write that .docbook format of documentation … :-)
I tried a little script to get meinproc4 to fail by executing several copies in
parallel.
for game in killbots kjumpingcube konquest kpat kubrick kgoldrunner palapeli
do
echo meinproc4 for $game
cd /kdedev/games/$game/doc && /opt/local/bin/meinproc4 --check --cache
/kdedev/build/games/$game/doc/index.cache.bz2
/kdedev/games/$game/doc/index.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. /keddev
is my KDE development area and /opt/local/bin is where MacPorts puts utilities
(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 Apple'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 at
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 to be
no replay
of the MacPorts command that started it), but there seem to be multiple
commands 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 backtrace
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 initialisation,
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, ignoring
the return
result. I can only conclude that the code is being executed for its
side-effects, 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.log,
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 somewhere
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 find a
locale.
One final idea. I see that there is a version of meinproc4 called
meinproc4_simple,
which the KDE translators use for some purpose which I cannot quite make out.
Anyway, it appears to be a special-purpose version of meinproc4 and it is
essentially
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 only
takes
in a .docbook file, checks it and spits out a .cache.bz2 file, thus omitting
the code where
meinproc4 appears to be crashing in the Apple OS X environment. That version
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 unsubscribe <<
