Qt mobility 1.1 contact action plugin on Nokia n900 (Maemo5 Fremantle)

MarekR22

Hi,

I'm trying add new action to some of contacts in address book.
I found a good documentation how to do it with Qt Mobility 1.1.
So I almost copy paste "this example":http://doc.qt.nokia.com/qtmobility-1.1/contactsactions.html#example-implementation. My modifications are cosmetic (different class names and some constants, only one extra action).

I update phone with repository:
deb http://repository.maemo.org/extras-devel/ fremantle-1.3 free non-free
So Qt mobility can be installed on phone (with required dependences).

Now when I fallow instruction "how to deploy the plugin":http://doc.qt.nokia.com/qtmobility-1.1/contactsactions.html#deployment-on-maemo5 I get a Segmentation Fault! I noted that library is loaded before error but no relevant code of plugin (from example) is run.
After installing debug version of servicefw and my plug in I can see this call stack:

bq. Program received signal SIGSEGV, Segmentation fault.
0x00013c54 in QHashData::firstNode (this=0x4a090) at /usr/include/QtCore/qhash.h:187
187 /usr/include/QtCore/qhash.h: No such file or directory.
in /usr/include/QtCore/qhash.h

0x00013c54 in QHashData::firstNode (this=0x4a090) at /usr/include/QtCore/qhash.h:187

0x00014288 in QHash<QString, int>::constBegin (this=0xbea217f8) at /usr/include/QtCore/qhash.h:462

0x0000f708 in QtMobility::ServiceMetaData::latestInterfaces (this=0xbea217d0) at ../../src/serviceframework/servicemetadata.cpp:640

0x0000f884 in QtMobility::ServiceMetaData::parseResults (this=0xbea217d0) at ../../src/serviceframework/servicemetadata.cpp:204

0x40048c3c in QtMobility::QServiceManager::addService(QIODevice*) () from /usr/lib/libQtServiceFramework.so.1

0x40048ea0 in QtMobility::QServiceManager::addService(QString const&) () from /usr/lib/libQtServiceFramework.so.1

0x0001af18 in CommandProcessor::add (this=0xbea21b58, args=...) at servicefw.cpp:214

0x0001b3ec in CommandProcessor::qt_metacall (this=0xbea21b58, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0xbea2192c) at ../../build/Debug/servicefw/moc/servicefw.moc:79

0x40e57be4 in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4

0x40e5b40c in QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const () from /usr/lib/libQtCore.so.4

0x0001de60 in QMetaMethod::invoke (this=0xbea21aa4, object=0xbea21b58, val0=..., val1=..., val2=..., val3=..., val4=..., val5=..., val6=..., val7=..., val8=..., val9=...)

at /targets/FREMANTLE_ARMEL/usr/include/QtCore/qmetaobject.h:134

0x0001b774 in CommandProcessor::execute (this=0xbea21b58, options=..., cmd=..., args=...) at servicefw.cpp:119

0x0001be98 in main (argc=3, argv=0xbea21d04) at servicefw.cpp:513

Note that in call stack is no reference to my plugin, only qt and qtm code is present!
Line servicemetadata.cpp:640 (this is qtm code) refers to fetching a const iterator:
@QList<QServiceInterfaceDescriptor> ServiceMetaData::latestInterfaces() const
{
QList<QServiceInterfaceDescriptor> interfaces;
QHash<QString,int>::const_iterator i = m_latestIndex.constBegin(); // here is crush servicemetadata.cpp:640
while(i != m_latestIndex.constEnd())
{
interfaces.append(serviceInterfaces[i.value()]);
++i;
}
return interfaces;
}@

So anyone has experience similar problem?
What I'm doing wrong? Or maybe this is qtm bug on Meamo5 and I should report it?

Any help will be appreciated.

chriadam

Hi Marek,

This does sound like a bug in the service framework library on Fremantle.
But, to be sure:

If you build the mobility unit tests, can you attempt to register the test actions with servicefw and see if the result is the same?
If you run servicefw without specifying --system parameter, does it still segfault?
Instead of using the servicefw tool, you can (in application code) call QServiceManager::addService(xmlpath) to add the service to the QServiceManager's scope (you can try both UserScope and SystemScope).

From the provided stack trace, it looks like a bug in QServiceManager itself, so I wouldn't hold too much hope that you'll be able to work around this issue, unfortunately; but I might be wrong.

Are you doing anything strange (loading Qt as a plugin, doing stuff in your install/remove hook of your service plugin which might corrupt random memory locations, etc)? Presumably not, but I've seen the servicefw tool exhibit "strange behaviour" due to these sort of things, before.

Cheers,
Chris.

MarekR22

[quote author="chriadam" date="1298590450"]1) If you build the mobility unit tests, can you attempt to register the test actions with servicefw and see if the result is the same?[/quote]Maybe I will try this, currently project was canceled :/ so it will be hard to find time to do this.

[quote author="chriadam" date="1298590450"]2) If you run servicefw without specifying --system parameter, does it still segfault?[/quote]I already tried with and without this parameter. Result is always the same.

[quote author="chriadam" date="1298590450"]3) Instead of using the servicefw tool, you can (in application code) call QServiceManager::addService(xmlpath) to add the service to the QServiceManager's scope (you can try both UserScope and SystemScope).[/quote]This requires writing installation application, so this is not a nice solution. Also It is highly possible that same problem will appear.

[quote author="chriadam" date="1298590450"]From the provided stack trace, it looks like a bug in QServiceManager itself, so I wouldn't hold too much hope that you'll be able to work around this issue, unfortunately; but I might be wrong.[/quote]When I do those unit test on n900 then I will file a bug report.

[quote author="chriadam" date="1298590450"]Are you doing anything strange (loading Qt as a plugin, doing stuff in your install/remove hook of your service plugin which might corrupt random memory locations, etc)? Presumably not, but I've seen the servicefw tool exhibit "strange behaviour" due to these sort of things, before.[/quote]No, nothing! Like I said my code is almost exact copy of example from documentation.

chriadam

Hi,

One other thing I should ask: do the normal service framework unit tests fail?
If the service framework module unit tests pass, but the contact action related unit tests fail, then that suggests an error in our QContactActionManager plugin, or something similar. However, if the service framework unit tests also fail, then I'd say that everything is pointing to this being a bug with QServiceManager on Maemo5, which would need to be reported.

Cheers,
Chris.