Qt-interest Archive, February 2007
Passing implictly shared classes over plugin boundaries evil?
Message 1 in thread
Hi,
I suppose I know the answer, but it never hurts to double check. :-)
Implicitly shared classes are really something nice, but could it be
that it is evil to pass one from a plugin to the main program?
I got some nasty memory corruptions/double free messages when I tried to
do this.
Now converted everything to ptrs and all is well.
Guido
--
[ signature omitted ]
Message 2 in thread
I take it back. On another computer my original code works fine. Must be
a different problem.
Guido
On Tue, Feb 13, 2007 at 05:27:27PM +0100, Guido Seifert wrote:
> Hi,
> I suppose I know the answer, but it never hurts to double check. :-)
>
> Implicitly shared classes are really something nice, but could it be
> that it is evil to pass one from a plugin to the main program?
>
> I got some nasty memory corruptions/double free messages when I tried to
> do this.
>
> Now converted everything to ptrs and all is well.
>
> Guido
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 3 in thread
Caution: if a computer it goes wrong and on anoter id doesn't,
probabily it have an error.
If the error is double free, it's almost certain that your code is wrong.
To make it easy: if you do
pointer = something;
free(pointer); // frees the memory
free(pointer); // implementation indipendet!
this means that one C++ implementation *may* be safe for double delete
on a platform, but also may be not.
But from my experience, a double free is always your error. Look
toward delete code, distruptors and object slicing.
Also i sudjest to use valgrind to profile your source.
Bye
On 2/13/07, Guido Seifert <wargand@xxxxxx> wrote:
> I take it back. On another computer my original code works fine. Must be
> a different problem.
>
> Guido
>
> On Tue, Feb 13, 2007 at 05:27:27PM +0100, Guido Seifert wrote:
> > Hi,
> > I suppose I know the answer, but it never hurts to double check. :-)
> >
> > Implicitly shared classes are really something nice, but could it be
> > that it is evil to pass one from a plugin to the main program?
> >
> > I got some nasty memory corruptions/double free messages when I tried to
> > do this.
> >
> > Now converted everything to ptrs and all is well.
> >
> > Guido
> >
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> > List archive and information: http://lists.trolltech.com/qt-interest/
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 4 in thread
On Tue, Feb 13, 2007 at 11:10:54PM +0100, Alessandro Re wrote:
> Caution: if a computer it goes wrong and on anoter id doesn't,
> probabily it have an error.
> If the error is double free, it's almost certain that your code is wrong.
Looks more like I had some old .o files with incompatible abi.
> But from my experience, a double free is always your error. Look
> toward delete code, distruptors and object slicing.
Nothing there. Did not even work with pointers. Some corruption the the
glibc and the double free part was only an aftereffect. I bet when I
make a distclean on the libs and the main program tomorrow the bug is
gone on the other computer, too.
Not too much experience with Qt's plugin system. No deeper knowledge
and still a little distrust of Qt's implicit sharing there. So it was
easy to point fingers and blame both of them . ;-)
Guido
--
[ signature omitted ]
Message 5 in thread
Guido Seifert schrieb:
> On Tue, Feb 13, 2007 at 11:10:54PM +0100, Alessandro Re wrote:
>> Caution: if a computer it goes wrong and on anoter id doesn't,
>> probabily it have an error.
>> If the error is double free, it's almost certain that your code is wrong.
>
> Looks more like I had some old .o files with incompatible abi.
Looks like you're compiling on Unix/Linux: FYI in Visual Studio you
_have_ to compile all your DLLs against the "Multithreaded [Debug] DLL"
(the important bit here being the "DLL" in the name) runtime library.
Only when there's a "DLL" in the name do you get one single address
space for all your DLLs and your *.exe.
Else every DLL will have it's own copy of the C/C++ runtime library and
also it's own address space. Hence when you allocate memory in one DLL A
and want to delete it in DLL B you will get memory corruption.
(The solution for such a case is to provide explicity create()/destroy()
functions for objects to be created from outside the respective DLL, so
that an object is always created/destroyed in the same DLL.)
AFAIK On Unix/Linux by default all your shared objects share the same
address space, so there should be no problem with Qt's implicitly shared
objects such as QString - at least that's my experience with all
compilers I've encountered so far (g++, native AIX, SGI, Tru64...
compilers). But maybe with recent compilers you also have switches where
you can control the memory address space, just like on Windows?
But sometimes "make clean; make" performs miracles, too ;)
Cheers, Oliver
--
[ signature omitted ]
Message 6 in thread
> But sometimes "make clean; make" performs miracles, too ;)
For me all the miracle I needed this time. *blush* ;-)
Guido
--
[ signature omitted ]
Message 7 in thread
Guido Seifert schrieb:
> Implicitly shared classes are really something nice, but could it be
> that it is evil to pass one from a plugin to the main program?
>
> I got some nasty memory corruptions/double free messages when I tried to
> do this.
Sounds familiar...
I had a similar case lately, when I freed a DLL while a part of it (a
QTranslation object) was still registered in the QApplication object
which belonged to another DLL. On unloading the last DLL I got a bang!
You may want to check for this case; who creates an object, frees it.
Martin
--
[ signature omitted ]
