[PyKDE] "import khtml" causes weird problem

[Jim Bublitz]

On Thursday 09 February 2006 09:03, D Bera wrote:
> > It could be a problem with KURL::List - there are two 'filePreview'
> > functions:
> >
> > namespace KIO
> > {
> >    KIO::PreviewJob* filePreview (KURL::List, ...)
> >    KIO::PreviewJob* filePreview (KFileList, ...)
> > }
> >
> > where KFileList is a mapped type of QPtrList<KFileItem>. I haven't looked
> > at that (the second function) yet, beyond one attempt where I ran into a
> > problem in the KFileItem ctor where the C++ code is trying to figure out
> > the mime type of the file and I ran into a segfault somewhere in the Qt
> > unicode processing code. The second function is basically just a call to
> > the KIO::PreviewJob ctor; the first function converts the KURL::List to a
> > KFileList and the calls the KIO::PreviewJob ctor.
>
> Yeah!
> [debajyoti at dbera yabipy]$ python
> Python 2.4.1 (#2, Aug 25 2005, 18:20:57)
> [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> from qt import QString
> >>> from kio import *
> >>> from kdecore import *
> >>> s = QString ('image/jpeg')
> >>> u = KURL ('/home/debajyoti/out')
> >>> import stat
> >>> m = stat.S_IFREG
> >>> i = KFileItem (u, s, m)
>
> Segmentation fault

I spent some more time on this tonight. Creating a KFileItem works fine if you 
have a KApplication instance, as does filePreview (KFileItemList, ...) which 
rules out any KURL::List related problems. Also, constructing a 
KIO.PreviewJob object directly, without calling the global functions works 
fine too. "Works fine" in this case means works correctly if you don't import 
kparts or khtml and crashes if you do. I also made everything persistent, on 
the off chance something was getting garbage collected - no change.

Here's what sip executes:

        const KFileItemList * a0;
        int a0IsTemp = 0;
        int a1;
        int a2 = 0;
        int a3 = 0;
        int a4 = 70;
        bool a5 = 1;
        bool a6 = 1;
        const QStringList * a7 = 0;

        if (sipParseArgs(&sipArgsParsed,sipArgs,"M1i|
iiibbJ0",sipConvertToTransfer_KFileItemList,&a0,&a0IsTemp,&a1,&a2,&a3,&a4,&a5,&a6,sipClass_QStringList,&a7))
        {
            KIO::PreviewJob *sipRes;

            printf ("%i items\n", a0->count ()); // added manually

            sipRes = KIO::filePreview(*a0,a1,a2,a3,a4,a5,a6,a7);

            printf ("%i items\n", a0->count ());  // added manually

            if (a0IsTemp)
                delete const_cast<KFileItemList *>(a0);

            return sipMapCppToSelfSubClass(sipRes,sipClass_KIO_PreviewJob);

Both printfs print before the preview pops up - all of the PreviewJob work is 
done in C++ after the ctor returns (a QTimer invokes all of the action). The 
item counts for the KFileItemList (just a QPtrList<KFileItem>) are correct in 
both places - the list is getting clobbered (both in type and length) later 
by something that happens in the C++ world, before the return to the Python 
world when the 'gotPreview' signal fires.

There isn't anything that sip or PyKDE or the Python program can do to affect 
what goes on at that point, therefore it just about has to be a bug in the 
KDE C++ code. I'm not sure how you'd prove that - maybe rewriting the program 
in C++ and linking it to libkparts or libkhtml, or manually loading one of 
those from the C++ program, but I don't know if that would really duplicate 
what's going on with the imports. I doubt it would.

This works perfectly on my production machine. It currently uses sip 4.1.1, 
but it also runs KDE 3.3.0. The program works there with or without the 
imports that cause problems elsewhere. I assumed it was the older sip 
version, but it could just as well be the older KDE version that doesn't 
exhibit the problem. I can try an older version of KDE with a new sip version 
later this weekend if I get a chance. If that's the case, I can try diff'ing 
the kparts or khtml KDE versions and see if anything turns up.

I can't even suggest a possible workaround - maybe loading khtml in a 
different Python module or as a separate process. Otherwise it looks like 
this isn't going to work for the time being. I'm not set up to debug inside 
KDE.

Jim