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

List:       kde-mac
Subject:    Re: [KDE/Mac] The meinproc4 segfault is finally REPRODUCIBLE
From:       <mk-lists () email ! de>
Date:       2015-04-29 5:53:50
Message-ID: 8D732970-C322-4735-8B65-4D62CB4BAF1E () email ! de
[Download RAW message or body]

Hi Ian,

On 29 Apr 2015, at 01:16 , Ian Wadham <iandw.au@gmail.com> wrote:
> Thanks for pinpointing the lines where meinproc4 fails [1].  I think these Macports logs
> must require a reading age of about 325… :-)  I cannot make head nor tail of them.
> Otherwise I would have replied sooner.

:)


> Look back a few lines for occurrences of the string "meinproc4".  

Yes, thanks for spotting that. Indeed, the cache file is used twice by 2 processes
running in parallel! I think meinproc4 should protect its cache against such double-use!!!


> Try running the build with one stream only or perhaps with the manpage omitted
> from the build and see if the problem goes away.

I have given the advice to use build.jobs=1 as an option for "port install" on MacPorts'
trac ticket [ https://trac.macports.org/ticket/47496#comment:28 ].


> I notice that meinproc4 is coming from /opt/local/bin. In previous logs (builds of
> kdelibs4), meinproc4 itself was being re-built and the newly built version was being
> used further on in the build when it crashed, so maybe that caused the problem
> somehow.  So, good, another hypothesis can be discarded for now.

meinproc4 built every time it ought to be used?


> IF it is a concurrency problem, a crash log might not tell us much.  

Yep.


> It is what happened
> a few milliseconds *before* the crash that matters.  That is what led to the crash.  Also
> on-line debuggers are of little use with timing-dependent problems, because they alter
> the timing and so the problem goes away.

All clear. I hope vazspam can verify that with building sequentially.


> If it looks like a concurrency problem, we will need a "black box" recorder (as in an
> airliner) to diagnose it.  I wonder if you can turn on log-file output in meinproc4, using
> kdebugdialog.app.  That might tell us more about the process leading up to the crash.

Oh, I haven't thought about using kdebugdialog.app yet. But that's another possibility, if 
for some obscure reason the sequentialisation of this build doesn't resolve the issue for
vazspam.

Greets,
Marko

_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac
[prev in list] [next in list] [prev in thread] [next in thread]