Hello Przemek
Przemysław Czerpak wrote: > > BTW it was also very good example which shows how important is > built in protection against wrongly released GC blocks. Without > it such bugs can exists for years causing random crashes. > +1. > BTW I've just tested demoqt using valgrind and below is an error > which invalid memory access which may be source of GPF traps reported > by some users here. Looks that inside release_QWidget there is nothing > to protect against multiple releasing of QWidges. > Maybe it's time to switch to the code with dynamically registered > casting functions I sent few weeks ago? > It should resolve this problem and also some others like common for > all widgets destructor function which forces to link all QT components. > It will be also good starting point for deeper modifications. > BTW using valgrind you can create very precise list of allocated and > never freed memory blocks. If you want then I can send such log here. > Can you do the same test with demoxbp? I am in a better position to understand if I get this info about demoxbp than demoqt. I have generator code in place to implement what you sent few days ago. That is exceptionally accurate code no doubts, but I run into problems because not all the pointers are created with "new" in our constructor code. Few are sent just as plain pointers by QT itself which also are accessed via our param access functions. I could not make out howto handle all the situations, so did not implement. Of late I was struggling with unreleased memory when next invocation of a dialog is made. I did sent the logs to the list. In this coming week, I will again give your code another look and will try to implement. But perhaps I need your "serious" help in this direction. Waiting such logs for demoxbp. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/CPU-Consumption-and-hb_idleState%28%29-tp26240902p26256802.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
