>One reason for this may be current default HBQT_RELEASE_WITH_DELETE_LATER memory releasing mode. Just one observation, to be more precise, in hbqt the default is overwritten, as I remember correctly.
Best regards, István -----Original Message----- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts Sent: 2009. december 15. 14:16 To: Harbour Project Main Developer List. Subject: Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes Thanks. It's half guessing, but it may mean that not all QT objects are released by HBQT at HVM deinit. One reason for this may be current default HBQT_RELEASE_WITH_DELETE_LATER memory releasing mode. The name suggest that this mode is also a way to hide possible problems (GPFs) when using pointer references to objects which are already released. And looking at HBQT code, there are quite a few places where this is possible. If this is true, first HBQT should be fixed to not require such solution. After that we may use overriding of C++ allocation operators. Brgds, Viktor On 2009 Dec 15, at 13:54, Bisz István wrote: > Hi, > > I got the same negative results as in the first tentative described in my > previous mail. See attachment. > > Best regard, > István > > -----Original Message----- > From: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts > Sent: 2009. december 15. 13:07 > To: Harbour Project Main Developer List. > Subject: Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC > without USE_DL_PREFIX) crashes > > Hi, > >>> We already have part of this enabled in fm.c, but only >>> when building core in C++ mode, and if FMSTAT is enabled. >> >> I tried to activate this part with: >> >> @set HB_BUILD_MODE=cpp >> @set HB_USER_CFLAGS=-DHB_FM_STATISTICS >> in hbqt.hbc: >> from: >> {allgcc}libs=supc++ >> to: >> {allgcc}libs=hbvm supc++ (maybe there are more sophisticated >> approaches to eliminate the double defined new/delete build errors ) >> >> But hbide and demoqt crashes on exit, see below... > > This looks a little bit hybrid solution, so I'm > not confident it's safe to do. For sure duplicates > on new/delete doesn't look healthy. Speccing > hbvm as user lib is also not recommended and > may have side effects. > > It'd be better to test it by including source > below in hbqt lib, and use it with default Harbour > build. > > --- > #include "hbapi.h" > > void * operator new[]( size_t size ) > { > return hb_xgrab( size ); > } > > void * operator new( size_t size ) > { > return hb_xgrab( size ); > } > > void operator delete[]( void * ptr ) > { > hb_xfree( ptr ); > } > > void operator delete[]( void * ptr, size_t ) > { > hb_xfree( ptr ); > } > > void operator delete( void * ptr ) > { > hb_xfree( ptr ); > } > > void operator delete( void * ptr, size_t ) > { > hb_xfree( ptr ); > } > --- > >>> Maybe we should create a small contrib lib with just >>> that, so that it could be used by any C++ contribs we >>> may happen to have in the future (plus hbqt of course). >> >> OK, it is useful I think, but will generate other problems as we can see. >> >> I just proposed a similar handling of the fm.c mingw build with the MSC >> build. >> More exactly to insert in the subsequent logic the #define USE_DL_PREFIX > for >> MinGW. I haven't enough knowledge of the HVM internals to do it, sorry. >> ... >> # elif defined( _MSC_VER ) >> # if !defined( USE_DL_PREFIX ) && !defined( HB_FM_DLMT_ALLOC ) >> # define USE_DL_PREFIX >> # endif >> # if defined( HB_OS_WIN_CE ) >> # define LACKS_FCNTL_H >> # endif >> ... >> This part generates the different MSC and MinGW default builds behavior, > as >> I understood correctly. > > This is less optimal solution, but we already do it for > MSVC, so we can enable it for MinGW also, if it turns > out to be the only solution. > > Brgds, > Viktor > > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > <hbqt_base.zip>_______________________________________________ > 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 _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
