QtMobility Contacts API: Can't create QContactManager object on Nokia 5800 - app crashing
-
Hey,
I am on Nokia 5800, Qt 4.7.3, Qt mobility 1.1.3.
I need to fetch contacts. When I do - QContactmanager cm; or QContactmanager *cm =new QContactManager(); or QContactmanager::AvailableManagers(); my app crashes with the debugger showing a Segmentation Fault at these lines.Here is what I m doing:
@
void Contacts::FetchContacts()
{
qDebug()<<"here1";/* QStringList strlist = QContactManager::availableManagers(); qDebug()<<strlist.count(); for(int i=0;i<strlist.count();i++) { qDebug()<<strlist.at(i); }*/ QContactManager cm; // or QContactManager cm("symbian"); qDebug()<<"here2"; QList<QContactLocalId> contactIds = cm.contactIds(); QContact currContact; qDebug()<<contactIds.count(); foreach (const QContactLocalId& id, contactIds) { currContact = cm.contact(id); QString nameAndNumber(currContact.displayLabel() + ": " + currContact.detail(QContactPhoneNumber::DefinitionName).value(QContactPhoneNumber::FieldNumber)); ui->listWidget->addItem(nameAndNumber); }
}
@
In Application output I receive "here1" and then a segmentation fault occurs and app crashes before printing "here2".Any help in this regard would be apreciated.
Thanks -
It could be related to missing capabilities. Try adding
@symbian: {
TARGET.CAPABILITY = ReadUserData WriteUserData
} @to your application.
-
@Fuzzbender Thanks for reply...but I already have these lines in my .pro
-
It looks like someone else has already reported this issue:
https://bugreports.qt.nokia.com/browse/QTMOBILITY-1915
Please vote on that task or provide any extra information you can (a backtrace of the crash, in particular, would be useful - QtCreator with fshell should be able to get you more information, I believe). -
To be honest I don't know if this will help or not, but try http://labs.qt.nokia.com/2011/04/15/introducing-muxcons/
As for getting a real debugger stacktrace from the device, I'm certain there is a way, but I personally don't know of one. Does the debugging inbuilt in QtCreator give a proper stack trace (eg, something similar to the output of gdb's "bt" command from the site of the segfault)? If so, paste it here and I can take a quick look at it.
Cheers,
Chris. -
Following is a part of the trace I receive :
~"GNU gdb (GDB) 7.2\n" ......
dUSING GDB VERSION: 70200, BUILD: 2010
2^done,features=["frozen-varobjs","pending-breakpoints","thread-info","python"]
dFEATURES: 2^done,data={features=["frozen-varobjs","pending-breakpoints","thread-info","python"]}
d
&"set breakpoint pending on\n"
3^done
&"set print elements 10000\n"
4^done
&"set overload-resolution off\n"
5^done
&"handle SIGSEGV nopass stop print\n"
~"Signal Stop\tPrint\tPass to program\tDescription\n"
~"SIGSEGV Yes\tYes\tNo\t\tSegmentation fault\n"
6^done
&"set unwindonsignal on\n"
7^done
&"pwd\n"
~"Working directory C:\Users\Shrey Jairath.\n"
8^done
&"set width 0\n"
9^done
&"set height 0\n"
10^done
&"set auto-solib-add on\n"
11^done
12^done
13^done
&"A syntax error in expression, near0'.\n" 14^error,msg="A syntax error in expression, near
0'."
15^done
16^done
17^done
~"dumpers=[{type="QLinkedList",formats=""},{type="QSize",formats=""},.......type="QSet",formats=""},],hasInferiorThreadList="0"\n"
18^done
&"symbol-file "C:/QtSDK/Symbian/SDKs/Symbian1Qt473//epoc32/release/gcce/udeb/ContactFetch.sym"\n"
~"Reading symbols from C:/QtSDK/Symbian/SDKs/Symbian1Qt473//epoc32/release/gcce/udeb/ContactFetch.sym..."
sReading C:/QtSDK/Symbian/SDKs/Symbian1Qt473//epoc32/release/gcce/udeb/ContactFetch.sym......
~"done.\n"
19^done
&"set breakpoint always-inserted on\n"
20^done
&"set breakpoint auto-hw on\n"
21^done
&"set trust-readonly-sections on\n"
22^done
&"set displaced-stepping on\n"
23^done
&"set mem inaccessible-by-default\n"
24^done
&"mem 0x00400000 0x70000000 cache\n"
25^done
&"mem 0x70000000 0x80000000 cache ro\n"
26^done
&"set remotecache on\n"
27^done
&"target remote 127.0.0.1:2314\n"
~"Remote debugging using 127.0.0.1:2314\n"
&"warning: limiting remote suggested packet size (131072 bytes) to 16384\n"
limiting remote suggested packet size (131072 bytes) to 16384=thread-group-started,id="i1",pid="42000"
sThread group i1 created
dTaking notice of pid 42000
=thread-created,id="1",group-id="i1"
sThread 1 created
~"0xc913ddb0 in ?? ()\n"
*stopped,frame={addr="0xc913ddb0",func="??",args=[]},thread-id="1",stopped-threads="all"
28^done
sSetting breakpoints...
dSetting breakpoints...
<29maint print msymbols C:/Users/SHREYJ~1/AppData/Local/Temp/gdb_ns_.Of1092
&"maint print msymbols C:/Users/SHREYJ~1/AppData/Local/Temp/gdb_ns_.Of1092\n"
29^done
dFOUND NON-NAMESPACED QT
dNOTE: INFERIOR SETUP OK
dState changed from InferiorSetupRequested(4) to InferiorSetupOk(6).
dState changed from InferiorSetupOk(6) to EngineRunRequested(7).
dQUEUE: RUN ENGINE
dCALL: RUN ENGINE
dNOTE: ENGINE RUN AND INFERIOR STOP OK
dState changed from EngineRunRequested(7) to InferiorStopOk(14).
dNOTE: INFERIOR RUN REQUESTED
dState changed from InferiorStopOk(14) to InferiorRunRequested(10).
sRunning requested...
<30-exec-continue
30^running
dNOTE: INFERIOR RUN OK
dState changed from InferiorRunRequested(10) to InferiorRunOk(11).
*running,thread-id="all"
Thread 6477 reported
[Qt Message] here1=thread-group-exited,id="i1"
sThread group i1 exited
*stopped,reason="exited-normally"
sApplication exited normally
dNOTE: INFERIOR EXITED
dState changed from InferiorRunOk(11) to InferiorExitOk(16).
dState changed from InferiorExitOk(16) to InferiorShutdownOk(19).
dState changed from InferiorShutdownOk(19) to EngineShutdownRequested(20).
dQUEUE: SHUTDOWN ENGINE
dCALL: SHUTDOWN ENGINE
dINITIATE GDBENGINE SHUTDOWN IN STATE 0, PROC: 2
<31-gdb-exit
CODA disconnected
31^exit
dGDB CLAIMS EXIT; WAITING
dGDB PROCESS FINISHED, status 0, code 0
dNOTE: ENGINE SHUTDOWN OK
dState changed from EngineShutdownRequested(20) to EngineShutdownOk(22).
dState changed from EngineShutdownOk(22) to DebuggerFinished(23).
dQUEUE: FINISH DEBUGGER
dNOTE: FINISH DEBUGGER
dHANDLE RUNCONTROL FINISHED
sDebugger finished. -
That's possibly useful information (I don't know enough about Symbian to be sure either way) but it's not a stack trace (ie, list of function calls which lead to the crash/segfault). Anyway, I suggest posting this information in that bug report as a comment, as it may help the developer who is fixing it to pinpoint the exact issue. I hope the issue is resolved soon, good luck!