[KDE/Mac] The meinproc4 segfault is finally REPRODUCIBLE

[Marko Käning]

Hi Ian,

On 29 Apr 2015, at 01:16 , Ian Wadham <iandw.au at 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