[KDE/Mac] The meinproc4 segfault is finally REPRODUCIBLE

[Ian Wadham]

Hi Marko,

On 29/04/2015, at 3:53 PM, Marko Käning wrote:
> On 29 Apr 2015, at 01:16 , Ian Wadham <iandw.au at gmail.com> wrote:
>> 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!!!

In meinproc4, --cache is not a cache in the usual sense.  It is an output file containing
compressed HTML pages and files, which will be decompressed only when the user
opens the Handbook for the relevant app or library.  The second process is NOT using
that option.  It is generating a manpage and using --stylesheet.

The possibility exists that the two different uses of meinproc4 are somehow incompatible,
on OS X, if they happen to be run at the same time.

>> 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 ].

Yes, but don't get too excited just yet…  Let's see what vazspam comes back with when
he tries build.jobs=1.  Who produced the log being discussed in
https://trac.macports.org/ticket/47496#comment:29?

Was it you or vazspam?  Was that log produced with build.jobs=1?  Looks like not, to me.
No mention of build.jobs=1 in that log and still two meinproc4 crashes.
> 
>> 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?

No, I think MacPorts builds everything in kdelibs4 regardless (if you are building from
source)… and that includes meinproc4… The freshly built meinproc4 is then used to
build docs for other stuff in kdelibs4.  At least, that is what was happening years ago
before MacPorts was providing prebuilt binaries.

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

Notice that I said "IF".

>> 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.

Ditto.

>> 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.

Cheers, Ian W.