happens only on meego?
is possible to produce a backtrace?

It works for me after package update of 'plasma-mobile-config-meego' with commits:
[Marco Martin] use xrender on meego
[Marco Martin] add sample-media

Following Mer images are still effected:

2012-05-14-13-36-basyskom-plasma-active-devel-0-20120517-0-1-mer-next-usb-live.iso
2012-05-14-12-42-basyskom-plasma-active-devel-mer-usb-live.iso

<snip>
Application: Files (kdeinit4), signal: Segmentation fault
[KCrash Handler]
#7  0x4dc630cd in QEglContext::createSurface(QPaintDevice*, QEglProperties const*) () from /usr/lib/libQtGui.so.4
#8  0x434f88b8 in ?? () from /usr/lib/libQtOpenGL.so.4
#9  0x434a9e90 in QGLWidget::event(QEvent*) () from /usr/lib/libQtOpenGL.so.4
#10 0x4d58bf6c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#11 0x4d591203 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#12 0x4e4a88bb in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#13 0x4cf23673 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#14 0x4d5e41f5 in QWidget::setParent(QWidget*, QFlags<Qt::WindowType>) () from /usr/lib/libQtGui.so.4
#15 0x4d5e471f in QWidget::setParent(QWidget*) () from /usr/lib/libQtGui.so.4
#16 0x4da4a253 in QAbstractScrollArea::setViewport(QWidget*) () from /usr/lib/libQtGui.so.4
#17 0x4ef22489 in KDeclarativeView::setUseGL(bool) () from /usr/lib/libactiveapp.so.0
#18 0x4ef216a3 in KDeclarativeMainWindow::KDeclarativeMainWindow() () from /usr/lib/libactiveapp.so.0
#19 0x4ef2a740 in ?? () from /usr/lib/libkdeinit4_active-filebrowser.so
#20 0x4ef2a57e in kdemain () from /usr/lib/libkdeinit4_active-filebrowser.so
#21 0x0804f3d3 in _start ()
<snap>

(In reply to comment #2)
> It works for me after package update of 'plasma-mobile-config-meego' with
> commits:
> [Marco Martin] use xrender on meego
> [Marco Martin] add sample-media

It works for me on MeeGo as well now.

Mer (at least on x86) with today's (05-26) updates is still affected with this bug.

It also does not show any resources (only applications and widgets) in the Add Resource dialog, maybe this is releated...

The parameter "-graphicssystem raster" in active-imageviewer.desktop and active-filebrowser.desktop is not working probably because they are launched by kdeinit4_wrapper. I tried adding "QT_GRAPHICSSYSTEM=raster" to /usr/share/kde4/apps/startactive/env.conf but the crash still happens even though the variable was added to the process environment. The only workaround I have found so far for this problem is changing the Exec= line in the .desktop to:

Exec=/bin/true; exec active-filebrowser --resourceType=nfo:Image -graphicssystem raster %u

The "/bin/true; exec" part forces kdeinit to launch a shell  to execute Exec= line and then it works without crashes. Do you think this hack is acceptable?

Until we find a proper solution, yes. It's not beautiful, but it's way better than a crash on startup.

Git commit 2e28cf782543f2bd0585e4211b0ca004c97e923b by Lamarque V. Souza.
Committed on 30/05/2012 at 02:31.
Pushed by lvsouza into branch 'master'.

Add workaround for crash when launching active-browser.

M  +4    -1    applications/filebrowser/active-filebrowser.desktop
M  +3    -1    applications/filebrowser/active-imageviewer.desktop

http://commits.kde.org/plasma-mobile/2e28cf782543f2bd0585e4211b0ca004c97e923b

The problem with Add Resource dialog showing only applications and widgets is because soprano is failing to start and thus nepomuk cannot save resource data when indexing files. I have not figured out why soprano is failing. Sometimes it fails  right after the user account is created, then startactive stalls during session startup and there is only a black screen. In .xsession-errors I can see the messages:

[/usr/bin/nepomukservicestub] "01:42:50 Compiler unit is timed at 0.001221 msec
"
[/usr/bin/nepomukservicestub] "01:42:51 Roll forward started
"
[/usr/bin/nepomukservicestub] "01:42:51 The transaction log file has been produced by different server instance.
"
[/usr/bin/nepomukservicestub] "01:42:51 Server exiting
"
[/usr/bin/nepomukservicestub] Virtuoso server stopped: 3
[/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(6699)" Soprano: "Failed to start Virtuoso"
[/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(6699)" Soprano: "Failed to start Virtuoso"
[/usr/bin/nepomukservicestub] nepomukstorage(6699)/nepomuk (storage service) Nepomuk2::Repository::open: Unable to create model for repository "main"

ops, sorry, it is virtuoso that is failing, not soprano.

Ok, virtuoso is failing because the /usr/bin/setup-kde-skel, which run as normal user, does not have permission to read the files in /etc/skel/.kde/share/apps/nepomuk/. One of the files there is exactly a pre-filled nepomuk database. Running: 

chmod 644 $(find /etc/skel/.kde/share/apps/nepomuk/ -type f )
chmod 755  $(find /etc/skel/.kde/share/apps/nepomuk/ -type d )

Allows virtuoso to run but "Add Resource" still does not show the other resources. I do not like giving permission to all files in  /etc/skel/.kde/share/apps/nepomuk/ , that means anybody in the system can read the nepomuk database from any user.

Another problem is that /usr/bin/setup-kde-skel was always overriding the contents of ~user/.kde, including the nepomuk database. I fixed this last problem in plasma-mobile.

"I do not like giving permission to all files in /etc/skel/.kde/share/apps/nepomuk/ , that means anybody in the system can read the nepomuk database from any user."

shouldn't the files in /etc/skel be copied to the user's home dir on first boot (or even sooner with a pre-made user home dir in an image), and not be used directly for storing any information after that?

yes, the files in /etc/skel are read when starting without home to build a template.

they should be readable by everybody (not writable)

another thing, this crash appears to happen only with intel drivers, so is again a graphics driver related issue

(In reply to comment #13)
> yes, the files in /etc/skel are read when starting without home to build a
> template.
> 
> they should be readable by everybody (not writable)

I mean after the home dir is created (mer or meego), the read permissions are kept, so anybody can read the nepomukdatabase of users mer or meego. ~/.kde should not be world readable like it currently is in my opinion.

The script /usr/bin/setup-kde-skel copies the /etc/ske/.kde over the home directory during first boot. The system also does the same when creating the home dir, so setup-kde-skel should not repeat the process.

shouldn't be the home dir not world readable in the first place?

(In reply to comment #16)
> shouldn't be the home dir not world readable in the first place?

In PA case I think you're right. That also depends on how paranoic you are :-)

Files and Images now don't crash on start anymore (though they still don't show any files,  probably because of the other bug in this report).
However, the workaround still has to be put into the Books and Reader (active-documentviewer) apps as they still crash. Hm, so we actually have to implement the workaround for a bug in most core PA applications? Not so nice...

(Btw: Sorry that I have merged two actually seperate bugs into one, I thought they had the same root cause but obviously they didn't have.)

The workaround is not in the applications, it is in how they are launched. klauncher is the daemon responsible for launching programs in KDE, it first tries to launch programs using kdeinit, which is an old (~10 years) workaround to speed up launching C++ programs (because of a deficiency in the code generated by g++, that deficiency is not that severe now so kdeinit is not really needed nowadays). What the workaround does is disabling kdeinit to force klaunch to use the executables in /usr/bin instead of the libs /usr/lib/libkdeinit4*.so (well, actually the former also uses the libs, but that is not that relevant now). Theoretically that should make launching programs a bit slower, but that is better than crashing.

For some reason kdeinit is ignoring the QT_GRAPHICSSYSTEM environment variable and the -graphicssystem parameter passed in the Exec= line of the .desktop files. I will add the workaround for active-documentviewer.

Yes, the second problem has nothing to do with the crashes. For some reason some ontologies are not being loaded into nepomuk (I used nepomukshell to check that). Document/* and Image/RasterImage are some of the missing ontologies and without them the file indexer cannot add the data about any document or raster image (most image format files are raster images, including .jpg, .png, etc).

I can trigger the ontology loading using "qdbus org.kde.nepomuk.services.nepomukontologyloader /nepomukontologyloader org.kde.nepomuk.OntologyManager.updateAllLocalOntologies", I can see nepomuk loading them in ~/.xsession-errors (including the files that contains the Document/* and Image/RasterImage), there is no apparent error but they do not show up in nepomukshell.

Git commit fe7a893097e77679fe7caa42f8671acfa9b2d620 by Lamarque V. Souza.
Committed on 30/05/2012 at 21:33.
Pushed by lvsouza into branch 'master'.

Add workaround for crash when launching active-filebrowser.

M  +3    -2    applications/filebrowser/active-books.desktop

http://commits.kde.org/plasma-mobile/fe7a893097e77679fe7caa42f8671acfa9b2d620

the launch time benefits can probably be offset with prelinking. what can't be is the few MB of memory per application that gets saved with a kdeinit style launcher.

note also that the crash is happening with intel chipsets (may happen with others, but so far we've only seen it there).

a more proper fix would probably be to not build the applications as kdeinit launched apps but regular binaries.

that means changing kde4_add_kdeinit_executable in the CMakeLists to just kde4_add_executable. then these workarounds in the .desktop files which trigger the launch of a shell (another process!) can be removed.

i'd much, much rather see that approach than the workaround. in fact, i'll go make that change right now.

Git commit 304248e799c2ccd1420b6df9e9630c3ec4047dad by Aaron Seigo.
Committed on 30/05/2012 at 22:53.
Pushed by aseigo into branch 'master'.

don't build this as a kdeinit4 exec. triggering crashes in Qt opengl code on intel chipsets.

M  +1    -3    applications/filebrowser/active-books.desktop
M  +1    -3    applications/filebrowser/active-filebrowser.desktop
M  +1    -3    applications/filebrowser/active-imageviewer.desktop
M  +2    -3    applications/filebrowser/src/CMakeLists.txt
M  +1    -2    applications/filebrowser/src/main.cpp

http://commits.kde.org/plasma-mobile/304248e799c2ccd1420b6df9e9630c3ec4047dad

Another clue about the nepomuk problem: the ontologies are being loaded into nepomuk with a different hierarchy. It used to be Resource -> Document and Resource -> Image. Now they are Resource -> InformationElement -> Document and Resource -> InformationElement -> Media -> Visual -> Image. All documents and images are listed there, so probably our list models/dataengines are doing the wrong query to list them.

Another thing, long ago Trueg told me not to use AbstractMetadataModel::propertyUrl in plasma-mobile/components/metadatamodel/abstractmetadatamodel.h and use the Nepomuk::Vocabulary and Soprano::Vocabulary directly. Maybe that has something to do with the problem since now plasma-mobile is using Nepomuk2.

I can confirm that the crashes are fixed for all applications affected.

For the Nepomuk problem I created bug 300957 so please move the discussion regarding that problem there. Sorry again for mixing the two.