Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
Hi Istvan, > Hi Viktor, > > As I have o more argues and we are back to some original issues, I am > stopping to write more on this thread. > But an another case should be analyzed too: if we define HB_FM_STD_ALLOC, > everything goes well, without crashes. It's also a system-wide setting (which BTW has a large performance hit for most targets), but most importantly it's also just a random shot in the dark (AFAICS). Until we find out what is the real problem, such solutions would only mask or delay the real problem, so it's nothing more than a hack (with bad side-effects). Fixing HBQT problems by swapping such basic components like memory allocator or MT/ST mode HVM, moreover on a per platform/compiler basis, looks wrong to me. We should understand what's going on exactly and fix it at appropriate level. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: RE: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
> In previous messages you said that it crashes on application exit. > Now on 1-st delete operator. So where it crashes really? On application exit when the first delete operator is executed. -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak Sent: 2009. december 15. 14:40 To: Harbour Project Main Developer List. Subject: Re: RE: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes On Tue, 15 Dec 2009, Bisz István wrote: Hi, > >I can define USE_DL_PREFIX as default in ST builds but I'm afraid that > >it will only hide some problems in HBQT code instead of resolving them. > The default ST with VS2008 woks, just the default ST with MinGW fails on > the first delete operator. In previous messages you said that it crashes on application exit. Now on 1-st delete operator. So where it crashes really? Anyhow we still do not know why it crashes. Tests which checks that it works in one configuration but does not work in other only help to reduce the problem but are not enough to give an answer what and where is exactly broken. Errors like GPF caused by accessing released memory can be very easy hidden by any modifications which change even a little bit memory allocation strategy and/or addresses of allocated memory blocks so pointers read from freed memory area can be still valid. Program will stop GPF but it does not mean that anything was fixed. It's still broken as it was and sooner or later the problem will be exploited again. 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
RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
Hi Viktor, As I have o more argues and we are back to some original issues, I am stopping to write more on this thread. But an another case should be analyzed too: if we define HB_FM_STD_ALLOC, everything goes well, without crashes. 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:37 To: Harbour Project Main Developer List. Subject: Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes >> 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. I guess you meant demoqt, and you're right. demoqt sets memory release mode to HBQT_RELEASE_WITH_DELETE. Although in this case it's also possible that it is this setting which makes demoqt fail, while the others HBQT apps work. BTW, here demoqt still doesn't make a GPF on exit, using plain default TDM-DW2-MinGW build wit 4.6.0 QT. I still hold my opinion that we should not have such setting in release quality code like HBQT_RELEASE_WITH_*. This triples possible testing scenarios and apparently no one has any clue why some of them works and some not. For testing it's fine, but eventually we should chose the best for HBQT purposes and make that work in stable way. Brgds, Viktor ___ 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
Re: RE: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
On Tue, 15 Dec 2009, Bisz István wrote: Hi, > >I can define USE_DL_PREFIX as default in ST builds but I'm afraid that > >it will only hide some problems in HBQT code instead of resolving them. > The default ST with VS2008 woks, just the default ST with MinGW fails on > the first delete operator. In previous messages you said that it crashes on application exit. Now on 1-st delete operator. So where it crashes really? Anyhow we still do not know why it crashes. Tests which checks that it works in one configuration but does not work in other only help to reduce the problem but are not enough to give an answer what and where is exactly broken. Errors like GPF caused by accessing released memory can be very easy hidden by any modifications which change even a little bit memory allocation strategy and/or addresses of allocated memory blocks so pointers read from freed memory area can be still valid. Program will stop GPF but it does not mean that anything was fixed. It's still broken as it was and sooner or later the problem will be exploited again. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
>> 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. I guess you meant demoqt, and you're right. demoqt sets memory release mode to HBQT_RELEASE_WITH_DELETE. Although in this case it's also possible that it is this setting which makes demoqt fail, while the others HBQT apps work. BTW, here demoqt still doesn't make a GPF on exit, using plain default TDM-DW2-MinGW build wit 4.6.0 QT. I still hold my opinion that we should not have such setting in release quality code like HBQT_RELEASE_WITH_*. This triples possible testing scenarios and apparently no one has any clue why some of them works and some not. For testing it's fine, but eventually we should chose the best for HBQT purposes and make that work in stable way. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
>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
> ___
> 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
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
> ___
> 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
Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
>> Are you using single thread HVM intentionally? > > No, in MT everything is ok, but I was rejected by Viktor, argued that MT > generates ~40% performance reduction. I rejected it because it doesn't seem like a _real_ solution, just a hack which accidentally (or at least for unknown reason) works. IOW, we need to find the root of the problem instead of masking it. The other reason is that forcing MT - or any optional mode whatsoever - isn't a right solution for any problem. Or we shouldn't call such "option" an option. _MT_ is an option (and not default) in Harbour because it may cause existing user code to break, plus it has a significant performance hit on several targets. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
Hi,
> Are you using single thread HVM intentionally?
No, in MT everything is ok, but I was rejected by Viktor, argued that MT
generates ~40% performance reduction.
> As long as USE_DL_PREFIX is not defined then DLMALLOC is not disabled
> on HVM exit so we should not have any problems on exit in valid code.
>This part has effect only for single thread HVM. In MT DLMALLOC builds
>HB_FM_DLMT_ALLOC is enabled by default so ONLY_MSPACES is defined as 1
>what disable all code using USE_DL_PREFIX.
>I can define USE_DL_PREFIX as default in ST builds but I'm afraid that
>it will only hide some problems in HBQT code instead of resolving them.
The default ST with VS2008 woks, just the default ST with MinGW fails on the
first delete operator.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
Sent: 2009. december 15. 13:28
To: Harbour Project Main Developer List.
Subject: Re: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC
without USE_DL_PREFIX) crashes
On Tue, 15 Dec 2009, Bisz István wrote:
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...
Are you using single thread HVM intentionally?
> >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.
As long as USE_DL_PREFIX is not defined then DLMALLOC is not disabled
on HVM exit so we should not have any problems on exit in valid code.
> 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 part has effect only for single thread HVM. In MT DLMALLOC builds
HB_FM_DLMT_ALLOC is enabled by default so ONLY_MSPACES is defined as 1
what disable all code using USE_DL_PREFIX.
I can define USE_DL_PREFIX as default in ST builds but I'm afraid that
it will only hide some problems in HBQT code instead of resolving them.
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
Re: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
On Tue, 15 Dec 2009, Bisz István wrote:
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...
Are you using single thread HVM intentionally?
> >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.
As long as USE_DL_PREFIX is not defined then DLMALLOC is not disabled
on HVM exit so we should not have any problems on exit in valid code.
> 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 part has effect only for single thread HVM. In MT DLMALLOC builds
HB_FM_DLMT_ALLOC is enabled by default so ONLY_MSPACES is defined as 1
what disable all code using USE_DL_PREFIX.
I can define USE_DL_PREFIX as default in ST builds but I'm afraid that
it will only hide some problems in HBQT code instead of resolving them.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
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
RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
Hi All,
>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...
>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.
Best regards,
István
==
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: c:\Downloads\harbour\contrib\hbqt\tests/demoqt.exe
[New thread 4220.0x72c]
warning: Page heap: pid 0x107C: page heap enabled with flags 0x3.
warning: AVRF: demoqt.exe: pid 0x107C: flags 0x80443027: application
verifier en
abled
warning: QApplication.cpp:212: HB_TR_DEBUG new_QApplication
133275 B 2 KB
warning: trace.c:96: HB_TR_ALWAYS HbQt_Set_Release_Method DEFAULT :
HBQT_RELEA
SE_WITH_DELETE_LATER
warning: trace.c:96: HB_TR_ALWAYS HbQt_Set_Release_Method SET :
HBQT_RELEA
SE_WITH_DELETE
warning: trace.c:96: HB_TR_ALWAYS
warning: trace.c:96: HB_TR_ALWAYS -b-
warning: QMainWindow.cpp:145: HB_TR_DEBUG new_QMainWindow
213332 B 20804 KB
warning: QWidget.cpp:169: HB_TR_DEBUG new_QWidget
213500 B 25640 KB
warning: QMenuBar.cpp:145: HB_TR_DEBUG new_QMenuBar
227903 B 25980 KB
warning: QMenu.cpp:142: HB_TR_DEBUG new_QMenu
24
7206 B 26076 KB
warning: QMenu.cpp:142: HB_TR_DEBUG new_QMenu
24
7782 B 26860 KB
warning: QToolBar.cpp:132: HB_TR_DEBUG new_QToolBar
265887 B 45720 KB
warning: QAction.cpp:150: HB_TR_DEBUG new_QAction
279963 B 45760 KB
warning: QAction.cpp:150: HB_TR_DEBUG new_QAction
280183 B 45988 KB
warning: QAction.cpp:150: HB_TR_DEBUG new_QAction
280403 B 46228 KB
warning: QStatusBar.cpp:131: HB_TR_DEBUG new_QStatusBar
294349 B 46912 KB
warning: QLabel.cpp:132: HB_TR_DEBUG new_QLabel
3
27333 B 47072 KB
warning: QPushButton.cpp:133: HB_TR_DEBUG new_QPushButton
360022 B 47956 KB
warning: QTableWidget.cpp:143: HB_TR_DEBUG new_QTableWidget
454992 B 50936 KB
warning: QBrush.cpp:113: HB_TR_DEBUG new_QBrush
4
60386 B 55616 KB
warning: QBrush.cpp:113: HB_TR_DEBUG new_QBrush
4
60486 B 55620 KB
warning: QTableWidgetItem.cpp:111: HB_TR_DEBUG
new_QTableWidgetItem
470010 B 55644 KB
warning: QTabWidget.cpp:136: HB_TR_DEBUG new_QTabWidget
491034 B 58792 KB
warning: QWidget.cpp:169: HB_TR_DEBUG new_QWidget
491202 B 58812 KB
warning: QWidget.cpp:169: HB_TR_DEBUG new_QWidget
491370 B 58832 KB
warning: QWidget.cpp:169: HB_TR_DEBUG new_QWidget
491538 B 58852 KB
warning: QTreeView.cpp:143: HB_TR_DEBUG new_QTreeView
517436 B 64360 KB
warning: QDirModel.cpp:136: HB_TR_DEBUG new_QDirModel
540043 B 66052 KB
[New thread 4220.0x65c]
[New thread 4220.0x13b8]
warning: QLineEdit.cpp:136: HB_TR_DEBUG new_QLineEdit
564610 B 69436 KB
warning: QComboBox.cpp:136: HB_TR_DEBUG new_QComboBox
589755 B 69824 KB
warning: QCheckBox.cpp:131: HB_TR_DEBUG new_QCheckBox
604072 B 70012 KB
warning: QSpinBox.cpp:130: HB_TR_DEBUG new_QSpinBox
636274 B 70328 KB
warning: QRadioButton.cpp:131: HB_TR_DEBUG new_QRadioButton
649664 B 70388 KB
warning: QTextEdit.cpp:149: HB_TR_DEBUG new_QTextEdit
681461 B 71548 KB
warning: QProgressBar.cpp:134: HB_TR_DEBUG new_QProgressBar
698361 B 71652 KB
warning: QListView.cpp:139: HB_TR_DEBUG new_QListView
720373 B 72300 KB
warning: QStringList.cpp:124: HB_TR_DEBUG new_QStrin
Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
Hi All,
>> It's possible. Replacing default malloc()/free() functions have to be
>> global. Some compilers may keep some hardcoded references to default memory
>> manager and in such case they will crash when memory pointers from two
>> different memory manager are mixed.
>> In this case with HBQT you are introducing C++ RTL which may use it's own
>> references to build in memory manager. It's possible that adding this code
>> to one of HBQT CPP files will resolve the problem:
>
>> void * operator new( size_t nSize ) { return hb_xgrab( nSize ); }
>> void operator delete( void * p ) { hb_xfree( p ); }
Here's QT docs about this topic:
http://doc.trolltech.com/4.5/qt-performance.html#alternative-memory-allocation
We already have part of this enabled in fm.c, but only
when building core in C++ mode, and if FMSTAT is enabled.
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).
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
Hi,
> It's possible. Replacing default malloc()/free() functions have to be global.
> Some compilers may keep some hardcoded references to default memory manager
> and in such case they will crash when memory pointers from two different
> memory manager are mixed.
> In this case with HBQT you are introducing C++ RTL which may use it's own
> references to build in memory manager. It's possible that adding this code to
> one of HBQT CPP files will resolve the problem:
> void * operator new( size_t nSize ) { return hb_xgrab( nSize ); }
> void operator delete( void * p ) { hb_xfree( p ); }
> You can test it but it may also create new one if some code does not cleanly
> removes all allocated objects before HVM exit which may also deinitialize
> some other memory managers.
Yes, it is desirable to have as many as possible memory management calls in a
single HVM managements/statistics, if it is possible.
Taking into consideration that we are in releasing stage, this approach should
be postponed after release freezing taking into consideration that the testing
takes a relative long time and possible new issues generation.
I can mention here, that Qt collects in a single cpp the MM calls and offers in
this way for special builds, maybe for harbour, the malloc()/free() capture.
But this will be a future task, s I see now.
> Enabling USE_DL_PREFIX resolves any possible conflicts with C/C++ RTL
> though it's less efficient. But if current state creates real problems
> then we should change it and enable full memory manager replacement
> only on explicit user request by some macro, i.e. HB_FM_DL_PREFIX_OFF.
If it is a solution for the upcoming release, we should freeze our
possibilities related to the working default built for both MSC and MinGW too.
>> Or maybe there are some other approaches like HB_FM_STD_ALLOC macro
>> definition.
>It's rather inefficients memory manager so for many users it will be
>hard to accept it.
OK, I accept this.
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] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
On Mon, 14 Dec 2009, Bisz István wrote:
Hi,
> Hi Przemek,
[...]
> My question is, do we need to force the USE_DL_PREFIX macro for the mingw
> default builds as for MSC?
It's possible. Replacing default malloc()/free() functions have to be
global. Some compilers may keep some hardcoded references to default
memory manager and in such case they will crash when memory pointers
from two different memory manager are mixed.
In this case with HBQT you are introducing C++ RTL which may use it's
own references to build in memory manager. It's possible that adding
this code to one of HBQT CPP files will resolve the problem:
void * operator new( size_t nSize ) { return hb_xgrab( nSize ); }
void operator delete( void * p ) { hb_xfree( p ); }
You can test it but it may also create new one if some code does not
cleanly removes all allocated objects before HVM exit which may also
deinitialize some other memory managers.
Enabling USE_DL_PREFIX resolves any possible conflicts with C/C++ RTL
though it's less efficient. But if current state creates real problems
then we should change it and enable full memory manager replacement
only on explicit user request by some macro, i.e. HB_FM_DL_PREFIX_OFF.
> Or maybe there are some other approaches like HB_FM_STD_ALLOC macro
> definition.
It's rather inefficients memory manager so for many users it will be
hard to accept it.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
Hi Przemek, In the last few weeks I tried to test in a Vista environment the hbqt and hbxbp libraries with the hbide, demoxpb and demoqt. The scope of my tests is the Qt 4.5 last patch release (4.5.3) and the new Qt 4.6 first released (4.6.0) with two development environments: 1. TDM-MinGW with GCC 4.4.1. 2. VS2008 with the latest SP2. The all test variants goes well, just in two cases I encountered GPF-s: A. demoqt and Qt 4.5.3 with TDM-MinGW B. demoqt and Qt 4.6.0 with TDM-MinGW In both cases the crash appears with default build at the first delete operator execution tentative. In the GDB with the Application Verifier enabled the crash appears as: warning: HEAP[demoqt.exe]: warning: Invalid address specified to RtlSizeHeap( 003B, 01A99C08 ) Program received signal SIGTRAP, Trace/breakpoint trap. 0x77068b2f in ntdll!DbgUiConvertStateChangeStructure () from C:\Windows\system32\ntdll.dll After searching for similar issues on the net, I concluded that the conflict appears due to the dual memory handling conflicts in this environment. Going deeper in this issue, I had positive test with USE_DL_PREFIX macro define at habour default build. An alternative solution is the harbour default build with HB_FM_STD_ALLOC macro define. If we build the harbour with cpp mode or build the demoqt with MT and default harbour build, everything is OK, the demoqt exits without crash. My question is, do we need to force the USE_DL_PREFIX macro for the mingw default builds as for MSC? Or maybe there are some other approaches like HB_FM_STD_ALLOC macro definition. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBQT demoqt
Just to report D:\harbour\contrib\hbqt\tests>hbmk2 demoqt -Lc:\qt\4.5.3\lib hbmk2: Processing local make script: hbmk.hbm Harbour 2.0.0beta3 (Rev. 13207) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'demoqt.prg'... Lines 3236, Functions/Procedures 23 Generating C source output to 'demoqt.c'... Done. demoqt.o:demoqt.c:(.data+0x98): undefined reference to `HB_FUN_QT_SETEVENTFILTER ' demoqt.o:demoqt.c:(.data+0xa8): undefined reference to `HB_FUN_QT_SETEVENTSLOTS' collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc.exe demoqt.o hbmk_2gzple.o-mwindows -Wl,--start-group -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lversion -lshlwapi -lQtCore4 -lQtGui4 -lQtNetwork4 -lQt UiTools -lpsapi -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -l rddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lh bpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomc tl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm 32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group -odemoqt.exe -LC:/HARB OUR/lib/win/mingw -L/../lib -Lc:/qt/4.5.3/lib -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
Hi Bruno Luciani wrote: > > Don't work here > Just comment out the section oStyle := QWindowsXPStyle():new() and check if it helps? Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/HBQT-demoqt-tp25919918p25930279.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] HBQT demoqt
Hi Bisz István wrote: > > As the ' QWindowsXPStyle' is not supported under linux; I changed the line > 142 in demoqt.prg from: >oStyle := QWindowsXPStyle():new() > to: >oStyle := QWindowsStyle():new() > So we need to comment out this function at all, Windows specific. > After this change the demo started and I can handled the all > functionalities > except 'WebPage' menu point [crash on line 603: oDlg:exec()] > as the 'exec()' is wrong in this context. > Thanks for the hints. I will see another way. > The demo also crashes at exiting, see attachment. > Thanks for this detailed analysis. It appears some pointer is being freed twice. Though this does not show up on Windows but I have to analyze the GC implementation in more detail. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/HBQT-demoqt-tp25919918p25930259.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
Don't work here Bruno 2009/10/16 Bisz István > Hi, > > >> Just for now compile as > > >> hbmk2 demoqt -Lc:\qt\4.5.3\lib -lxhb > > >> I will remove debug info after few days as I need to debug it > >> constantly until I get the desired results. > > >Some additional info for debugging from a CentOS 5.3 distro ... > > As the ' QWindowsXPStyle' is not supported under linux; I changed the line > 142 in demoqt.prg from: > oStyle := QWindowsXPStyle():new() > to: > oStyle := QWindowsStyle():new() > > After this change the demo started and I can handled the all > functionalities > except 'WebPage' menu point [crash on line 603: oDlg:exec()] > as the 'exec()' is wrong in this context. > > The demo also crashes at exiting, see attachment. > > Regards, > István Bisz > > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
Is not the problem , I take off the line that refers the .ico image file and the problem is the same Bruno 2009/10/16 Pritpal Bedi > > Hi > > > Bruno Luciani wrote: > > > > Error executing compiled demoqt > > > > Ubuntu 9.04 - Harbour Rev 12719 > > > > br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ls > > copy.png demoqt hbmk.hbm open.png save.png > > cut.png demoqt.prg new.png paste.png test.ico > > br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ./demoqt > > X Error: BadIDChoice (invalid resource ID chosen for this connection) 14 > > Major opcode: 1 (X_CreateWindow) > > Resource id: 0x2a2 > > > > I am not sure what could be the issue, only a guess, do > ubuntu supports .ico files? test.ico is used to display title-bar > application icon. Try to change the source to supply > some .png instead of .ico, may be that helps. > > Regards > Pritpal Bedi > > -- > View this message in context: > http://www.nabble.com/HBQT-demoqt-tp25919918p25929082.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
But a few commits below that sample works ok in ubuntu I try Bruno 2009/10/16 Pritpal Bedi > > Hi > > > Bruno Luciani wrote: > > > > Error executing compiled demoqt > > > > Ubuntu 9.04 - Harbour Rev 12719 > > > > br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ls > > copy.png demoqt hbmk.hbm open.png save.png > > cut.png demoqt.prg new.png paste.png test.ico > > br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ./demoqt > > X Error: BadIDChoice (invalid resource ID chosen for this connection) 14 > > Major opcode: 1 (X_CreateWindow) > > Resource id: 0x2a2 > > > > I am not sure what could be the issue, only a guess, do > ubuntu supports .ico files? test.ico is used to display title-bar > application icon. Try to change the source to supply > some .png instead of .ico, may be that helps. > > Regards > Pritpal Bedi > > -- > View this message in context: > http://www.nabble.com/HBQT-demoqt-tp25919918p25929082.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
Hi Bruno Luciani wrote: > > Error executing compiled demoqt > > Ubuntu 9.04 - Harbour Rev 12719 > > br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ls > copy.png demoqt hbmk.hbm open.png save.png > cut.png demoqt.prg new.png paste.png test.ico > br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ./demoqt > X Error: BadIDChoice (invalid resource ID chosen for this connection) 14 > Major opcode: 1 (X_CreateWindow) > Resource id: 0x2a2 > I am not sure what could be the issue, only a guess, do ubuntu supports .ico files? test.ico is used to display title-bar application icon. Try to change the source to supply some .png instead of .ico, may be that helps. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/HBQT-demoqt-tp25919918p25929082.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
Error executing compiled demoqt Ubuntu 9.04 - Harbour Rev 12719 Regards Bruno // br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ hbmk2 demoqt -Lc:\qt\4.5.3\lib -lxhb hbmk2: Processing local make script: hbmk.hbm hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg Harbour 2.0.0beta3 (Rev. 12719) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'demoqt.prg'... Lines 966, Functions/Procedures 20 Generating C source output to 'demoqt.c'... Done. br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ls copy.png demoqt hbmk.hbm open.png save.png cut.png demoqt.prg new.png paste.png test.ico br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ ./demoqt X Error: BadIDChoice (invalid resource ID chosen for this connection) 14 Major opcode: 1 (X_CreateWindow) Resource id: 0x2a2 X Error: BadIDChoice (invalid resource ID chosen for this connection) 14 Extension:149 (RENDER) Minor opcode: 4 (RenderCreatePicture) Resource id: 0x2a3 X Error: BadIDChoice (invalid resource ID chosen for this connection) 14 Major opcode: 1 (X_CreateWindow) Resource id: 0x2a4 demoqt: Fatal IO error: client killed br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ demoqt: Fatal IO error: client killed br...@notebook:~/harbour_svn/harbour/contrib/hbqt/tests$ / 2009/10/16 Pritpal Bedi > > Hi > > > Jerry Finuliar-2 wrote: > > > > D:\harbour\contrib\hbqt\tests>hbmk2 demoqt -Lc:\qt\4.5.3\lib > > hbmk2: Processing local make script: hbmk.hbm > > > > Just for now compile as > > hbmk2 demoqt -Lc:\qt\4.5.3\lib -lxhb > > I will remove debug info after few days as I need to > debug it constantly until I get the desired results. > > Regards > Pritpal Bedi > > -- > View this message in context: > http://www.nabble.com/HBQT-demoqt-tp25919918p25920232.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
Hi, all On Ubuntu Karmic (9.10 devel) trying to run demoqt compile with: harbour -build Harbour 2.0.0beta3 (Rev. 12718) Copyright (c) 1999-2009, http://www.harbour-project.org/ compiling... hbmk2 -lxhb demoqt.prg and running... ubu...@ubuntu-desktop:~/src/harbour/contrib/hbqt/tests$ ./demoqt i get... Unrecoverable error 6005: Exception SIGSEGV at address (nil) Called from QT_QSTYLE_STANDARDICON(0) Called from (b)QSTYLE(0) in ../../../TQStyle.prg Called from QWINDOWSXPSTYLE:STANDARDICON(0) in ../../../TQStyle.prg Called from MAIN(143) in demoqt.prg Application Internal Error - /home/ubuntu/src/harbour/contrib/hbqt/tests/demoqt Terminated at: 2009.10.16 09:05:08 Unrecoverable error 6005: Exception SIGSEGV at address (nil) Called from QT_QSTYLE_STANDARDICON(0) Called from (b)QSTYLE(0) in ../../../TQStyle.prg Called from QWINDOWSXPSTYLE:STANDARDICON(0) in ../../../TQStyle.prg Called from MAIN(143) in demoqt.prg Application Internal Error - /home/ubuntu/src/harbour/contrib/hbqt/tests/demoqt Terminated at: 2009.10.16 09:05:48 Unrecoverable error 6005: Exception SIGSEGV at address (nil) Called from QT_QSTYLE_STANDARDICON(0) Called from (b)QSTYLE(0) in ../../../TQStyle.prg Called from QWINDOWSXPSTYLE:STANDARDICON(0) in ../../../TQStyle.prg Called from MAIN(143) in demoqt.prg Hope this helps ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
> Just for now compile as > > hbmk2 demoqt -Lc:\qt\4.5.3\lib -lxhb It compile fine. But loading takes a while. Memory is now nearly stable. It GPF when accessing WebPage menu. > I will remove debug info after few days as I need to > debug it constantly until I get the desired results. Take your time. Ill test it again till then. Thanks, Jerry -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT demoqt
Hi Jerry Finuliar-2 wrote: > > D:\harbour\contrib\hbqt\tests>hbmk2 demoqt -Lc:\qt\4.5.3\lib > hbmk2: Processing local make script: hbmk.hbm > Just for now compile as hbmk2 demoqt -Lc:\qt\4.5.3\lib -lxhb I will remove debug info after few days as I need to debug it constantly until I get the desired results. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/HBQT-demoqt-tp25919918p25920232.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBQT demoqt
Hi, Im trying to compile demoqt.prg but I received the following messages: D:\harbour\contrib\hbqt\tests>hbmk2 demoqt -Lc:\qt\4.5.3\lib hbmk2: Processing local make script: hbmk.hbm Harbour 2.0.0beta3 (Rev. 12718) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'demoqt.prg'... Lines 966, Functions/Procedures 21 Generating C source output to 'demoqt.c'... Done. demoqt.o:demoqt.c:(.data+0x98): undefined reference to `HB_FUN_HB_TOOUTDEBUG' collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc.exe demoqt.o hbmk_xncwvv.o-mwindows -Wl,--start-group -lhbqt -lversion - lshlwapi -lQtCore4 -lQtGui4 -lQtNetwork4 -lQtWebKit4 -lsupc++ -lhbextern -lhbdeb ug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lg tgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd - lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -l oleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib - Wl,--end-group -odemoqt.exe -LC:/HARBOUR/lib/win/mingw -L/lib -Lc:/qt/4.5.3/lib Build Tools Harbour Build Info --- Version: Harbour 2.0.0beta3 (Rev. 12718) Compiler: MinGW GNU C 3.4.5 (32-bit) Platform: Windows XP 5.1.2600 Service Pack 3 PCode version: 0.2 ChangeLog last entry: 2009-10-15 18:43 UTC-0800 Pritpal Bedi (prit...@vouchcac.c om) ChangeLog ID: ChangeLog 12718 2009-10-16 01:57:48Z vouchcac Built on: Oct 16 2009 11:19:42 Build options: Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship) --- gcc -v Reading specs from c:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --wi th-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --dis able-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --d isable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --with out-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enabl e-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw-vista special r3) My env var: set path=%path%;c:\harbour\bin;c:\qt\4.5.3\bin;c:\mingw\bin set HB_INC_QT=c:\qt\4.5.3\include set HB_INSTALL_PREFIX=C:\HARBOUR What am I missing? TIA, Jerry -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
