Summary: | Crash on contactPtr->id() and contactPtr is not 0 | ||
---|---|---|---|
Product: | Telepathy | Reporter: | jeremias.bosch |
Component: | tp-qt | Assignee: | jeremias.bosch |
Status: | RESOLVED NOTOURBUG | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | critical | ||
Priority: | medium | CC: | ollisal |
Version: | unspecified | Keywords: | NEEDINFO |
Hardware: | ARM | ||
OS: | other | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
jeremias.bosch
2011-03-28 09:54:14 UTC
A dangling pointer or other memory corruption. Now, as Tp::ContactPtr is a reference-counted shared pointer, unless you're somewhere digging out the bare pointers from them and/or deleting the pointed-to contacts, both of which would be incorrect usage, the only way one could have a dangling Tp::ContactPtr is also memory corruption of the reference count field in the Contact or the pointer structure itself. So, could you please run your application in Valgrind (memcheck tool) to spot the source of the memory corruption? Failing that, could you post a minimal testcase reproducing this? One other reason how the reference counting could fail could be use of threads. All TpQt4 functionality must be used from a single thread only. This includes even delayed slot connections across threads for Tp::PendingOperation finishes etc. I dont get valgrind working. simple test is, Tp::ConnectionPtr connection = streamedMediachannel->connection(); Tp::ContactManagerPtr contactManager = connection->contactManager(); Tp::PendingContacts* pc = contactManager->contactsForIdentifiers( QStringList()<< mContactIdView->text() ); pc->contacts().first()->id(); (In reply to comment #2) > I dont get valgrind working. > > simple test is, > > Tp::ConnectionPtr connection = streamedMediachannel->connection(); > Tp::ContactManagerPtr contactManager = connection->contactManager(); > Tp::PendingContacts* pc = contactManager->contactsForIdentifiers( > QStringList()<< mContactIdView->text() ); You waited for the PendingContacts to finish, and checked that it was successful at this point, right? > pc->contacts().first()->id(); That aside, this is not a standalone case reproducing the issue. If you want us to Valgrind the issue for you, you must post code compilable and runnable stand-alone. Numerous applications incorporating the above or equivalent sequence of calls to the ones mentioned above (but correctly waiting for the PendingContacts to finish successfully) exist, with no reports of ill behavior. Therefore, you must post a *full, runnable test application reproducing the problem*, or get Valgrind working for yourself so you can run your current application in it. My time for this is really short. The code as you see it here is exactly the functional code (there was a check of pc->contacts().first()->notNull()) to ensure its valid. It should not crash. Dont expect a running testcase from me. Feel free to close this if you think its a good idea to ignore issues because reporters have other work. I would appreciate when you try to get stuff more stable and save. If the code is exactly that, then the issue is that you aren't waiting for the PendingContacts to finish. Just like any other PendingOperation, you must connect the finished(Tp::PendingOperation *) signal to a slot, and extract the result when that slot has been invoked, after you've checked that the operation was finished successfully (it might, in particular finish with a failure e.g. if you pass an invalid ID to it, or due to an internal error in the connection manager D-Bus service). If you try to extract information from the PendingContacts right after it has been created (at which point no D-Bus calls have been able to be made yet), its contacts() accessor will most likely return an empty list. Calling first() on an empty QList results in uninitialized behavior, namely either crashing or returning completely random data (in this case a random ContactPtr). Hence you getting an invalid ContactPtr. I strongly suggest adopting the use of Valgrind or other memory error checking tools. In this case, it would have reported that your call to QList<ContactPtr>::first() accessed uninitialized, or not-allocated memory. As for having no time, surely as a developer you must appreciate the fact that to be able to investigate bugs, one must have adequate information on how to reproduce the issue? A way to reproduce an issue being the essence of what a bug is about, anyway. And as this is a memory corruption bug, adequate information either is a full testcase for producing the memory state which triggers the issue, or a report from a memory access checker tool which has already analyzed potential issues in the memory usage pattern. Closing the bug. Please reopen if, having followed these steps, the problem still persists. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.