Bug 115825

Created attachment 13310 [details]
File used to trigger crash

Created attachment 13311 [details]
A backtrace

Backtrace of kdialog --getopenfilename when enabling the preview pane and then
clicking on the test.php file

Created attachment 13312 [details]
Another backtrace

Backtrace generated from kdialog --getopenfilename when activating the preview
pane while the test.php is selected

Created attachment 13313 [details]
stderr of kdialog during second test run

The stderr of kdialog --getopenfilename during the second test run (see
backtrace2)

Most kdebug areas are enabled
stdout file was empty.

The following lines were written to the Konsole window:
DCOP: register 'kdialog-4073' -> number of clients is now 1
kio_file: ========= LIST file:///home/kdedev =========
kio_file: ============= COMPLETED LIST ============
kio_file: ========= LIST file:///tmp =========
kio_file: ============= COMPLETED LIST ============
DCOP: unregister 'kdialog-4073'
DCOP: register 'anonymous-4077' -> number of clients is now 1
DCOP:  'anonymous-4077' now known as 'drkonqi-4077'
kio_file: ========= LIST file:///home/kdedev =========
kio_file: ============= COMPLETED LIST ============
kio_file: ========= LIST file:///tmp =========
kio_file: ============= COMPLETED LIST ============
kio_file: FileProtocol::stat details=2

Both of your backtraces point to the gcc bug in libstdc++.

Use GLIBCXX_FORCE_NEW=1 and complain to your distribution.

*** This bug has been marked as a duplicate of 111115 ***

The crash also happens with binary 3.4.2 packages which are not using the visibility patch.

Moreover the problem part which results in the audiopreview plugin being selected for PHP files is still open, isn't it?

If it happens, it would be a different bug. Both backtraces you pasted show a crash inside libstdc++'s pool allocator, which is the root cause of Bug 111115. If you can provide other backtraces, we will analyse.

Created attachment 13315 [details]
Backtrace of 3.4.2

This is the backtrace of the Debian SID 3.4.2 packages.

To my knowledge the are compiled without visibility support as it causes
problems on some platforms.

However the crash could of course still be something Debian or compiler
specific, but something else seems to be wrong if the audio plugin is getting
the request for the PHP preview

export GLIBCXX_FORCE_NEW=1

Solves the problem with the crash.

Still loads the audio preview though.
How about reopening it with severity "minor" for this second issue?
Maybe a problem of the MIME type handling, PHP is application/x-php (according to kfile), but has the Property::X-KDE-text with value true

Your third backtrace shows the same problem.

I did not understand your second issue.

> Your third backtrace shows the same problem.

Yeah, thought so.
I will check the Debian bug tracking system then. Must be something else than -fvisibility that causes this as well, the KDE packagers posted a lengthy email why they won't enable it before KDE4

> I did not understand your second issue.

Assuming that the preview works on MIME types it is kind of wrong to ask the audio plugin for a preview of PHP script files, I would have expected that the one for text files is used.

On Monday 07 November 2005 00:21, Kevin Krammer wrote:
> Moreover the problem part which results in the audiopreview plugin being selected for PHP files is still open, isn't it?


The code (from kio/kfile/kfilemetapreview.cpp) says

    if ( s_tryAudioPreview &&
         !mimeType.startsWith("text/") && !mimeType.startsWith("image/") )
    {
        if ( !haveAudioPreview )
        {
            KPreviewWidgetBase *audioPreview = createAudioPreview( m_stack );
            if ( audioPreview )
            {
                haveAudioPreview = true;
                (void) m_stack->addWidget( audioPreview );
                QStringList mimeTypes = audioPreview->supportedMimeTypes();
                QStringList::ConstIterator it = mimeTypes.begin();
                for ( ; it != mimeTypes.end(); ++it )
                    m_previewProviders.insert( *it, audioPreview );
            }
        }
    }

i.e. it creates an audiopreview object simply to be able to ask it "which mimetypes do you support".
I have no idea if this could be done better - cc'ing Carsten in case he has time to have a look.

Created attachment 13334 [details]
Possible improvement

I tried to use the KMimeType class to improve the handling of still unknown
types.

It seems to work until requesting the preview for "text/plain" because while it
gets there ti still doesn't show a text preview.
I also tried "text/*", no difference

On Tuesday 08 November 2005 14:04, Kevin Krammer wrote:
> I tried to use the KMimeType class to improve the handling of still unknown
> types.


You should probably iterate over the "parent mimetype" chain, since inheritance is
possible on multiple levels. No idea about the problem you mention though.

On Monday 07 November 2005 23:46, David Faure wrote:

> i.e. it creates an audiopreview object simply to be able to ask it "which
> mimetypes do you support". I have no idea if this could be done better -
> cc'ing Carsten in case he has time to have a look.


At that time, it couldn't be done any better :-( 

aRts knows the list of mimetypes it supports (through all those playObject 
plugins), so we have to instantiate some aRts class and ask it. No way around 
that.

Better would be if that information could be fetched separately, without 
loading libarts.so

Cheers
Carsten

Created attachment 13346 [details]
Improved patch

Now iterates over over the inheritance list.

It actually finds a provider when doing the text/* lookup after reading the
KDE-text property, so previewProviderFor() now also works for application/x-php


Unfortunately it doesn't result in a preview.

I will try to continue investigation tomorrow.

Created attachment 13359 [details]
Associated improvement for PreviewJob

KIO::PreviewJob also needs to check MIME Type inheritance and KDE-text property
as a fallback when there is no preview for a file's MIME Type itself

Looks good, feel free to commit if it works for you.

Thanks, comitted in 3.5 branch:
http://lists.kde.org/?l=kde-commits&m=113172381908573&w=2