On Monday 17 November 2014 12:07:36 Jeremy Whiting wrote:
> Ok, how can I fix the unload order then?
You don't. The libraries are unloaded in alphabetical order, but I might
change that later to a QHash and then the order is arbitrary and random.
Fix the problem in a different way. If necessary,
Ok, how can I fix the unload order then?
On Mon, Nov 17, 2014 at 12:02 PM, Thiago Macieira wrote:
> On Sunday 16 November 2014 18:18:07 Jeremy Whiting wrote:
> > ==22353== Address 0x1cd1b758 is not stack'd, malloc'd or (recently)
> free'd
>
> This looks like the case of accessing memory from a
On Sunday 16 November 2014 18:18:07 Jeremy Whiting wrote:
> ==22353== Address 0x1cd1b758 is not stack'd, malloc'd or (recently) free'd
This looks like the case of accessing memory from a plugin that has been
unloaded.
Note how the backtrace started from qlibraryCleanup in qlibrary.cpp, which is
Thomas,
Thanks for the pointer. I tried changing KIO::AccessManager's destructor to
this:
AccessManager::~AccessManager()
{
QObjectList childList = children();
Q_FOREACH(QObject *child, childList) {
QNetworkReply *reply = qobject_cast(child);
if (reply != 0) {
On Montag, 17. November 2014 00:38:03 CEST, Albert Astals Cid wrote:
El Dilluns, 17 de novembre de 2014, a les 00:33:17, Thomas Lübking va
escriure:
You do not happen to delete a bechilded member in the
destructor explicitly,
are you?
Why would this be wrong?
"Nothing"*
*in general, but:
Hmm, valgrind shows QNetworkAccessManager is reading some location it
shouldn't inside it's destructor:
==22353== Invalid read of size 8
==22353==at 0x59BE57E:
QExplicitlySharedDataPointer::~QExplicitlySharedDataPointer()
(in /home/jeremy/devel/kde/src/qt5build/qtbase/lib/libQt5Network.so.5.
I'm not deleting anything in the destructor except m_wallet which is a
KWallet. The crash is in the base class destructor QNetworkAccessManager.
I'll try valgrind. good idea.
On Sun, Nov 16, 2014 at 4:38 PM, Albert Astals Cid wrote:
> El Dilluns, 17 de novembre de 2014, a les 00:33:17, Thomas Lü
El Dilluns, 17 de novembre de 2014, a les 00:33:17, Thomas Lübking va
escriure:
> On Sonntag, 16. November 2014 21:50:03 CEST, Jeremy Whiting wrote:
> > #10 0x74e59150 in QObjectPrivate::deleteChildren (this=0xa12a10)
> > at
> > /home/jeremy/devel/kde/src/qt5/qtbase/src/corelib/kernel/qobj
On Sonntag, 16. November 2014 21:50:03 CEST, Jeremy Whiting wrote:
#10 0x74e59150 in QObjectPrivate::deleteChildren (this=0xa12a10) at
/home/jeremy/devel/kde/src/qt5/qtbase/src/corelib/kernel/qobject.cpp:1950
#11 0x74e57768 in QObject::~QObject (this=0xa0eff0,
__in_chrg=) at
/home
El Diumenge, 16 de novembre de 2014, a les 13:50:03, Jeremy Whiting va
escriure:
> Hey all,
>
> I recently fixed attica's plugin loading so it now finds and loads the
> attica_kde.so plugin but when applications using knewstuff (and thus
> attica) close it's giving a segfault when the PlatformDep
Hey all,
I recently fixed attica's plugin loading so it now finds and loads the
attica_kde.so plugin but when applications using knewstuff (and thus
attica) close it's giving a segfault when the PlatformDependent object is
destructed. I've not done much at all with plugins in the past, but I've
ne
11 matches
Mail list logo
