On 2010 Apr 11, at 10:23, francesco perillo wrote:
>> Yes. Plus check TOFIX notes in HBQT code, and it's
>> worth to carefully read Przemek's recent quick summary
>> of HBQT problems, there are some important issues
>> raised there which may help finding the right direction.
>> (f.e. confusing/mixing raw pointers with GC collected
>> ones, which is another clear GPF situation).
>
> Can you point me to this message ? Date would be enough.
Begin forwarded message:
> From: Przemysław Czerpak
> Date: 2010 March 12 11:42:00 CET
> To: "Harbour Project Main Developer List." <harbour@harbour-project.org>
> Subject: Re: [Harbour] GC Pointers - Anyway to detatch them ?
> Reply-To: "Harbour Project Main Developer List." <harbour@harbour-project.org>
>
> 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
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
