Cascades Development

[simon_hain]

this is the error message:
Process 76279971 (bb10) terminated SIGSEGV code=1 fltno=11 ip=79812b82(/base/usr/lib/qt4/lib/libQtCore.so.4.8.4@_ZN7QObject7connectEPKS_PKcS1_S3_N2Qt14ConnectionTypeE+0xf5) mapaddr=00112b82. ref=2e474000

I see QObject connect and something about connectiontype.

Anyhow, trying to store the result and access it from qml then.

[simon_hain]

I changed the implementation to access the results using getters, and it fails at the same place. At least i have narrowed it down a bit.

error message now is:
Process 77078691 (bb10) terminated SIGSEGV code=1 fltno=11 ip=78e738de(/base/usr/lib/qt4/lib/libQtDeclarative.so.4.8.4@_ZN24QDeclarativeScriptString14setScopeObjectEP7QObject+0x8cd) mapaddr=001738de. ref=00000013 bdslot=1

I am a bit unsure how to proceed, i thought the getter would work...

[markwilcox]

Are you still passing the object in using a signal as well?

Don't want to tell you stuff you already know but a seg fault is a memory access violation - the most common cause for that in application code by a mile is trying to access a pointer to an object that has already been deleted.

What owns the object you're trying to access and what is its lifetime?  If you're managing that youself then you might have a bug there.  If you're not sure (e.g. didn't set a parent) then it's possible you've passed ownership to the declarative engine and it has deleted it upon exiting the signal handler.

The link I posted earlier has all the nasty details on sharing access to objects with QML.

One other alternative to passing an object in a signal at all is to simply add the object to the root context and send a signal to say it's there. You can then copy the bits you want from the root context to the relevant QML properties to keep everything looking nicely structured (accessing things from the root context looks a bit much like global variables - even if just about everything in QML/JS is global anyway).

Hope that helps,

Mark

[simon_hain]

My plan is to have all QObjects linked in a tree, to clean up the memory, but at the moment i am just creating them without any deletion.
So (at least i think) the lifetime should be unlimited. Here is the part where i create it (it gets some more details etc, but that would be the basics):

QString errorMessage =  soapStruct["Error"].toString();
DataServiceError* dsError;
if (!errorMessage.isEmpty()){
	dsError = new DataServiceError();
	dsError->setErrorMessage(errorMessage);

 Could it be an issue that i currently don't set the parent for a new QObject? I want to utilize that when i add the clean-up code, but it is not there yet.

My latest approach was to send a signal "dataStored" and let the qml retrieve it itself, but this does not work either.

[markwilcox]

I'm not entirely clear on exactly what you're doing to share the data with QML now.  For example, calling methods on an object that's been deleted is just as bad as trying to read data in an object that's been deleted.

If you just create the object with new, don't set a parent in the constructor and let the pointer go out of scope then it will not be deleted unless you pass ownership somewhere - actually this is a classic source of memory leaks.  However, depending on how you pass the object into QML, the declarative engine may take ownership if it doesn't have a parent set.  Then the declarative engine decides (possibly incorrectly) when it is out of scope and should be deleted.

If you can post some more code, or a small example that reproduces the problem then I'd be happy to take a look.  Otherwise I'd suggest either creating the object from QML and managing the whole process via signals/Q_INVOKABLE functions so that the object lifetime is entirely managed by the declarative engine, or adding the object to the root context and signalling that it's available.

[simon_hain]

I made some getters and declared them Q_INVOKABLE.
After receiving the result from my webservice i store it and send a signal to the QML, which uses the invokable methods to access the objects.

I am aware of the "memory leak", i just wanted to resolve the general scenario before starting to clean up.

Without having a clue, it sounds reasonable that the engine assumes ownership, as i just create the object and throw it out there. The article you linked states that Q_INVOKABLE does not change the ownership though.

I don't think i can create a sample that reproduces the issue, the application is a port of existing apps on BB OS, Android and iOS and not very small...

[markwilcox]

>> I made some getters and declared them Q_INVOKABLE.
>> After receiving the result from my webservice i store it and send a signal to the QML, which uses the invokable methods to access the objects.

This is the critical bit... what class has the Q_INVOKABLE getters and how is the instance of it which stores the result from the webservice made visible to QML?

>> Without having a clue, it sounds reasonable that the engine assumes ownership, as i just create the object and throw it out there. The article you linked states that Q_INVOKABLE does not change the ownership though.

Calling a Q_INVOKABLE method will not cause owership to change but before you can do that, you must somehow pass the object to the declarative engine.  If you just called the getter on an instance of the type registered, QML would create a new object.  This is the bit I'm not entirely understanding at the moment.

>> I don't think i can create a sample that reproduces the issue, the application is a port of existing apps on BB OS, Android and iOS and not very small...

Yes, actually I'd happily try the whole project with details of relevant files/lines to look at but most people are not so happy sharing all of their code.

[simon_hain]

I have dubbed a class "DataService", it is created in the main class of the project and put into the qml using
qml->setContextProperty("dataService", dataService);

in qml i use it like this:

function requestData() {
//connect signals from dataservice
  dataService.dataServiceResultStored.connect(onDataServiceResultStored)
  activityIndicator.start();
  dataService.loadDataServicesData(backendId, pageName, pageId);
}

 dataservice then sends the signal dataServiceResultStored and the function onDataServiceResultStored is triggered.

there i am trying to access the get methods from dataservice, which are all declared Q_INVOKABLE.

[markwilcox]

Sounds like the object lifetime shouldn't be an issue - depends which overload of setContextProperty() is being used as to which environment owns the object I believe but it should be OK in any case - I assume you can still access other dataService methods?

Out of interest, why use separate getters here rather than simply setting properties of the dataService object?

[simon_hain]

I have resolved the issue, it was something completly else (cue in monty python).
see
http://supportforums.blackberry.com/t5/Native-Development/How-to-hunt-down-a-segfault/td-p/2011755

basically, i did not initialize all pointers as NULL, and on the second webservice call there was no error object set, so the pointer was not used and pointed somewhere random.

i used getters because they are a bit faster to write than Q_PROPERTY and it was only to test the code.
I am now moving back to the signal, i think it should work now with all pointers being properly NULL or NOT NULL instead of LIMBO.