Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Pritpal, I now think that in prg classes we should add destructor and destroy all the children at harbour level from there, so doing that ourself and not leaving the job to Qt The other test I want to do is to use object.deleteLater() but it is not a solution, is an hack ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi Pritpal, For now I am including above patch in my tests. And if it resolves crashes with the updated code, I will commit. Later we will be waiting for Przemek's commit to see it the same is done on GC levels. OK, sounds good. In any case if it fits to our needs is better than nothing temporarily. It's sufficient to solve the scenario just for the linked non QObject-s. In the future we should switch the QPointer-s to QWeakPointer-s, covering in this way probably the non QObject-s too, but this looks to be a long way. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Did you test this code ? I think, yes. Then prg level :addItem() method is missing, how you solved that? Manually writing in TQLayout.prg ? I have this function in TQLayout.prg ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi Pritpal, Did you test this code ? I think, yes. Yes, you are right, and the crash is gone on my Fedora12. Then prg level :addItem() method is missing, how you solved that? Manually writing in TQLayout.prg ? I replaced just QLayout.cpp. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi to everybody, I tried to solve the problem starting from the end, the delete... I wanted to intercept the delete and from the pointer going back to the harbour QGC_POINTER and nullify it From the end you cover all cases in a generic way.. Your solution is from another point of view, you disable the delete statement when GC destructor is called on children so the only way to REALLY destroy a child is to wait for parent deletion... this may solve some problems but, as said and as I understood your sample, we may have deveral hanging objects... Is it also necessary to implement the same logic for addWidget, but also a inverted logic for removeWidget and removeItem... More, we need to devise a standard way to generate such code from qth/include files from the actual generator I think it is very difficult, we should create an in-memory structure of calls and then generate code as automatically as possible... Anyway, congratulations for the finding... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi Francesco, More, we need to devise a standard way to generate such code from qth/include files from the actual generator I think it is very difficult, we should create an in-memory structure of calls and then generate code as automatically as possible... Yes, you are right, this patch is just the first step in the crash hunting. The next steps should be oriented to a more general dynamic approach. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Yes, you are right, this patch is just the first step in the crash hunting. The next steps should be oriented to a more general dynamic approach. This is an important patch because it started a new way for solving GPF... Now there are several protections against GPFs... - guarded pointers for objects deriving from QObject - your way when objects are parented at runtime - second parameter of *_gcAllocate_* set to false Still missing is full check on parameter types but Przemek already gave some ideas... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Istvan, in hbide.prg please comment all the :destroy() lines, there are a bunch together... I will try later... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Sorry Pritpal, you were correct. In the QLayout.qth file proposed by Istvan the line of addItem is commented and so the harbour class is not generated... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
A bit more tracing in the debug log
diff -r 020effeac192 harbour/contrib/hbqt/generatorF/hbqtgen.prg
--- a/harbour/contrib/hbqt/generatorF/hbqtgen.prg Thu Apr 15
09:56:57 2010 +0200
+++ b/harbour/contrib/hbqt/generatorF/hbqtgen.prg Thu Apr 15
22:52:42 2010 +0200
@@ -50,6 +50,8 @@
*
*/
/*--*/
+
+#define TRACE_QT_CALLS
#include common.ch
#include fileio.ch
@@ -1237,7 +1239,9 @@
aadd( txt_, + cWidget + iif( lList, void *, ) + * p; )
aadd( txt_, )
aadd( txt_,p = hbqt_par_ + cWidget + ( 1 ); )
-
+#ifdef TRACE_QT_CALLS
+ aadd( txt_, 'HB_TRACE( ' + s_trMode + ', (' +
upper( cWidget ) + '_' + upper( cHBFunc) + ' ) );')
+#endif
/* Insert parameters by reference */
IF ! empty( aPre )
FOR n := 1 TO len( aPre )
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Francesco, Since I'm trying to implement your changes in the generator, if you have a better version please send... My post doesn't contain any other info. I am happy if you can find the solution in the generator part. István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Since I got GPF in another point (removing the :destroy() part) of the code (releasing a QToolBar) I used the trace above to see what function calls were done on that QToolBar... they are addAction toggleViewAction setIcon at least one of them must have the change you proposed Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Since I got GPF in another point (removing the :destroy() part) of the code (releasing a QToolBar) I used the trace above to see what function calls were done on that QToolBar... they are addAction toggleViewAction setIcon at least one of them must have the change you proposed My experience is that the Qt objects should be released by a controlled pointer zeroing in the prg level, otherwise we are facing to GPF-s (not analyzed harbour internals...). ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Ok, just for trying to understand how it is possible to proceed and to
validate the idea I did some tests... I was able to remove a GPFs
changing some add* functions.
It was a manual work and I strongly believe it can't be done manually !
Just for reference I post here one of this changed functions, for code review:
HB_FUNC( QT_QMAINWINDOW_ADDTOOLBAR )
{
QGC_POINTER_QMainWindow * q;
QGC_POINTER * p;
HB_TRACE( HB_TR_DEBUG, (QMAINWINDOW_ADDTOOLBAR ) );
q = ( QGC_POINTER_QMainWindow * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 3 );
if ( p p-ph q q-ph )
{
HB_TRACE( HB_TR_DEBUG, ( QT_QMAINWINDOW_ADDTOOLBAR() Qt oject:
%p is attached to: %p, (void *) p-ph, (void *) q-ph) );
p-bNew = HB_FALSE;
if ( q q-ph )
( q-ph )-addToolBar( ( Qt::ToolBarArea ) hb_parni( 2 ), ( (
QToolBar *) p-ph ));
else
HB_TRACE( HB_TR_DEBUG, ( F=QT_QMAINWINDOW_ADDACTION FP=( q-ph
)-addAction( xx ); q-ph is NULL ));
}
}
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
I'm about to implement a -massivedebug switch to the generator
sample:
HB_FUNC( QT_QPUSHBUTTON_ISFLAT )
{
QPushButton * p;
HB_TRACE( HB, ( Entering function QT_QPUSHBUTTON_ISFLAT ) );
and with a bit more knowledge on parameters/object (also thanks to
Viktor generator2) we may also print the parameter passed and the
return value/pointer...
I also created my cppstub with some debug info inside... I need to
print more infos and then match one new with one delete
Ciao
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
