Hello.
Has anyone encountered spontaneous program termination problems of Qt apps?

I followed the MADDE hello world example (http://wiki.maemo.org/MADDE/Qt_Example), which compiles fine and creates a (seemingly) correct debian package that installs fine on the n900. I can post the code, project file and generated makefile if requested, but they are all generated by the “mad pscreate -t qt_simple qthello” command, as given in the MADDE tutorial.

The program is compiled on a Ubuntu 9.04 AMD64, and the package is copied over using the USB cable.

The hello world application starts as expected, but when left running on the device, it always terminates after about 2 minutes +- a couple of seconds. I have timed this. The window closes, but no error messages are displayed. The program works fine in Qt Simulator or when launched on the n900 from PC over the USB cable.

I have already tried flashing with latest FIASCO & eMMC, as that seems to be the default suggestion to fix problems, but the problem persists. I don't seem to have this problem with other applications, only the ones compiled by me

Any suggestions?

This usually happens when there is a segmentation fault happening in the application.

Sounds like you need to implement support for D-Bus communication with the app; I suspect you have it configured to advertise itself as supporting D-Bus, but haven't yet added the code to actually do so. A few of us have run afoul of this, as discussed in this thread. As mentioned there, this article outlines what's needed.

Thanks for the quick reply. Any Ideas on what might be causing the segmentation fault? The whole source code of the example program consists of only:

I can't see much room for error there !!

Anyone else care to try to compile the example and leave it running on the device for a few minutes and see what happens?

Thanks, I will read through the links tomorrow after a good nights sleep.

Hm.
I can't see any errors, either.

However, my own (a little more advanced) Qt app just ran on my N900 for more than a few minutes... so, I dunno...

The key point here is whether the app was launched from the command line or the application icon. When an app is launched from the command line, it's a standard process and acts pretty much as you'd expect with no interference from the environment. But when you launch an app from its icon in the UI, and that app has service files advertising its availability as a D-Bus service, then Maemo expects to be able to send messages to it (and periodically does so). This allows for ensuring that there's only one copy of the application open at a time, etc.

The upshot is that if you haven't actually added the few lines of C++ code needed to handle those D-Bus messages, the application will crash when the first message gets delivered to it because the code that's expected to be there isn't. As in erwi's experience, I typically noticed this occurring after the app had been open for a couple of minutes, even if it was idle; that's just when the next D-Bus communication from the system happened. The exact same binary launched from the command line would run fine for days, because launching it that way doesn't register it as a D-Bus service, and Maemo doesn't try sending any messages to it.

The fact that this keeps popping up as a baffling phenomenon highlights the need to handle this a little better; ideally fix Qt so it doesn't crash in this case, or at least update the documentation and examples so that people are more likely to get the implementation right the first time. It seems like MADDE is probably auto-generating the appropriate service config files, but isn't guiding people to write the matching C++ code that's needed.

DBUS is a service that clients connect to actively. If your application hasn't actively connected to it, no messages will be delivered. Unless the Qt runtime automatically connects to DBUS, no messages will ever be delivered.

Is there such code in the Qt framework?

If not, I'd be more inclined to guess that this is the result of the Hildon desktop terminating the application after not getting a reply to its message.