On Thu, 11 Mar 2010, Pritpal Bedi wrote:
Hi,
> I am looking for a solution where is GC pointer is
> detatched from "freeing" it, all other operations remaining
> the same.
You have to implement it.
Add to GC structure 'detached' member which will inform you destructor
code executed by our GC that it should not release the QT object.
QT Object should be 'detached' when they are attached to some other
objects and will be freed together with them.
I do not know the HBQT details but if possible I suggest to also clean
references to such object from GC pointer item so it will not be
longer accessible as stand alone object (it's enough to set NULL/0
to object pointer in GC block).
> It is possible that I am not been able to explain what I need properly.
>
> In hbQT we are been unable to know, at certain points, when
> Qt releases the pointer. As per inherent nature of pointers
> C or C++ does not set the value of pointer variable to NULL.
???
Sorry but this suggests that some code is broken or wrongly casted
and has to be fixed. You have to isolate such places to check where
exactly the problem appears to eliminate similar situations in the
future and of course fix them.
I do not understand current HBQT code so I cannot help in details.
Looks that you are using 'QPointer<> pq' only as some type of dummy
pointer which protects against multiple call to 'delete' operator
in GC pointer item destructor but it's not used at all to resolve
the main problem and blocking access to freed object for all other
code.
I also do not see any protection against wrong object casting and
raw pointer items are accepted what effectively blocks any serious
cleanups. Few months ago I sent code example which adds such protection
to this list.
You cannot make code which is only partially safe. It will never work
correctly. It has to be fully safe or it is extremely hard to locate
real sources of problems. I.e. due to unprotected ph member of
QGC_POINTER you can encapsulate pointer to some freed object in
hb_gcAlloc() block and return it to PRG code as GC pointer item.
>From the beginning it's wrong pointer so it will has to fail inside
GC release operation so you are looking for workarounds inside GC
pointer item destructors when in fact they do not create any problems.
The code is growing up and the number of potential problems is also
increased and it's harder to fully follow all internal dependencies.
Finally it's fighting with the ghosts. As long as the base things are
not really safe then resolving upper level problems seems to be waste
of time because no one can say what is the real source of problem.
> And hence when it is subject to freeing, GC does not
> know if it has already been freed and hence GPF's.
Yes of course. Such situations are unacceptable and definitely
have to be fixed. Our GC have to be informed that some objects
were released. QPointer<> calls should make it.
> I have a mechanism in place where all delete operations
> can be carried on as per Qt specs, I just want that the
> pointer is not freeed in GC. It will only detatch GC from it
> and will clear its stack.
Maybe I'm missing sth but seems that It will only hides the real bugs.
The easiest method is redirecting FREE message to dummy method which
does nothing. Functionally you will reach the same results. Memory leak
which eliminates the problem of accessing freed memory.
If you want to create really working solution then you have to start
from the beginning and fix the code using GC pointer items. If you need
sth like:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), iParam );
if( p && p->ph )
return p->ph;
else if( HB_ISPOINTER( iParam ) )
return hb_parptr( iParam ); /* TOFIX: In what cases is this needed?
Reference counting to avoid referring to freed pointers? */
else
return NULL; /* TODO: Still better if RTE. */
}
then it means that your code is wrong.
p->ph is not cleared when QT freese the object and:
else if( HB_ISPOINTER( iParam ) )
return hb_parptr( iParam );
means that you still have some completely unsafe pointer items
which can make memory corruptions and any create problems in any
other code.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
