[Harbour] undefined reference to `_imp__hb_gtSetDefault'

[Bisz István]

Hi Viktor,

 

The commands sequence:

 

set PATH=C:\MinGW-5.1.4\bin;c:\MinGW-5.1.4\mingw32\bin

c:\harbour\mingw\bin\hbmk2 -info -trace -oc:\harbour\mingw\demowvg.exe
c:\Downloads\harbour\contrib\gtwvg\tests\gtwvg.hbp
c:\Downloads\harbour\contrib\gtwvg\tests\demowvg.prg

 

generates the error:

 

C:\Users\ISTVN~1\AppData\Local\Temp/cc0zxsaV.o:hbmk_zg6n02.c:(.text+0x2f):
undefined reference to `_imp__hb_gtSetDefault'

 

after changing the line 1562 in hbmk2.prg:

 

CASE t_cCOMP $ "gcc|mingw"; tmp := "__attribute__ ((
dllimport ))"



into the lines:

 

CASE t_cCOMP == "gcc" ; tmp := "__attribute__ ((
dllimport ))"
CASE t_cCOMP == "mingw"   ; tmp := ""



the error disappears .

 

Best regards and congratulations,

István

 

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[10881] trunk/harbour

[Bisz István]

Hi Pritpal,

Could you please replace in hbqtgen.prg the line 2278:

   aadd( txt_, '   oMenuBar:show()  
  ' )

with:

   aadd( txt_, '   oWnd:setMenuBar( QT_PTROF( oMenuBar ) )  
  ' )

for a better menu bar functionality. This change has been tested on Vista. 
Thank you.

Regards,
István

-Original Message-
From: vouch...@users.sourceforge.net [mailto:vouch...@users.sourceforge.net] 
Sent: Friday, April 17, 2009 5:14 PM
To: harbour@harbour-project.org
Subject: [Harbour] SF.net SVN: harbour-project:[10881] trunk/harbour

Revision: 10881
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10881&view=rev
Author:   vouchcac
Date: 2009-04-17 15:13:38 + (Fri, 17 Apr 2009)

Log Message:
---
2009-04-17 08:07 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * harbour/contrib/hbqt/generator/hbqtgen.prg
  * harbour/contrib/hbqt/generator/qt45.qtp
  * harbour/contrib/hbqt/Makefile_gen
  * harbour/contrib/hbqt/hbqt.h
  + harbour/contrib/hbqt/hbqt_qclipboard.cpp
  + harbour/contrib/hbqt/TQClipboard.prg
+ Added QClipboard class.
! Fixed hbqt.h generation not to include #define version...

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/Makefile_gen
trunk/harbour/contrib/hbqt/generator/hbqtgen.prg
trunk/harbour/contrib/hbqt/generator/qt45.qtp
trunk/harbour/contrib/hbqt/hbqt.h

Added Paths:
---
trunk/harbour/contrib/hbqt/TQClipboard.prg
trunk/harbour/contrib/hbqt/hbqt_qclipboard.cpp


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[10881] trunk/harbour

[Bisz István]

Hi,

The main problem with the existing solution is that the MenuBar object:

   oMenuBar := QMenuBar():new( QT_PTROF( oWnd ) )

defined in demoqt isn't connected to the QMainWindow object. This fact can be 
easily checked by the QMainWindow resizing; the MenuBar doesn't follows this 
operation.
The proposed solution connects the MenuBar object to the QMainWindow object, 
correcting the QMainWindow behavior.

Regards,
István

-Original Message-
From: Pritpal Bedi [mailto:bediprit...@hotmail.com] 
Sent: Friday, April 17, 2009 6:55 PM
To: harbour@harbour-project.org
Subject: RE: [Harbour] SF.net SVN: harbour-project:[10881] trunk/harbour


Hi


Bisz István wrote:
> 
> Could you please replace in hbqtgen.prg the line 2278:
> 
>aadd( txt_, '   oMenuBar:show()
>
> ' )
> 
> with:
> 
>aadd( txt_, '   oWnd:setMenuBar( QT_PTROF( oMenuBar ) )
>
> ' )
> 
> for a better menu bar functionality. This change has been tested on Vista.
> Thank you.
> 

Can you explain a bit what artifacts it corrects?
I will change this though.

Regards
Pritpal Bedi


-- 
View this message in context: 
http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10881--trunk-harbour-tp23099638p23101550.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] SF.net SVN: harbour-project:[10885] trunk/harbour

[Bisz István]

Hi,

The Makefile doesn't generate the gtqtc lib. Maybe the library name is wrong, 
could you please review?
Thanks.
Regards,
István

-Original Message-
From: vouch...@users.sourceforge.net [mailto:vouch...@users.sourceforge.net] 
Sent: Sunday, April 19, 2009 2:48 AM
To: harbour@harbour-project.org
Subject: [Harbour] SF.net SVN: harbour-project:[10885] trunk/harbour

Revision: 10885
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10885&view=rev
Author:   vouchcac
Date: 2009-04-19 00:48:17 + (Sun, 19 Apr 2009)

Log Message:
---
2009-04-18 17:41 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * harbour/contrib/gtqtc/Makefile
! Adopted along hbqt/Makefile pattern.

  + harbour/contrib/gtqtc/tests/wvtext.prg
+ Added harbour/tests/wvtext.prg here also.
  Change in only HB_GT_QTC_DEFAULT.
  This facilitates the comparison between GTWVT and GTQTC
+ Added harbour/tests/tests.ico
  Used as hb_gtInfo( HB_GTI_ICONFILE, 'tests.ico' )

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/gtqtc/Makefile

Added Paths:
---
trunk/harbour/contrib/gtqtc/tests/test.ico
trunk/harbour/contrib/gtqtc/tests/wvtext.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[10886] trunk/harbour

[Bisz István]

Great job Pritpal,

Just one observation. Could you please modify the MenuBar object build of 
harbour/contrib/hbqt/tests/wvtext.prg in the same way as for demoqt.prg:

! oMenuBar:show() => oWnd:setMenuBar( QT_PTROF( oMenuBar ) )

I can't test it, just checked the sources.

Regards,
István

-Original Message-
From: vouch...@users.sourceforge.net [mailto:vouch...@users.sourceforge.net] 
Sent: Sunday, April 19, 2009 2:59 AM
To: harbour@harbour-project.org
Subject: [Harbour] SF.net SVN: harbour-project:[10886] trunk/harbour

Revision: 10886
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10886&view=rev
Author:   vouchcac
Date: 2009-04-19 00:59:06 + (Sun, 19 Apr 2009)

Log Message:
---
2009-04-18 17:48 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * harbour/contrib/hbqt/generator/hbqtgen.prg
  * harbour/contrib/hbqt/generator/qt45.qtp
  * harbour/contrib/hbqt/hbqt.h

  + harbour/contrib/hbqt/hbqt_qtextblock.cpp
  + harbour/contrib/hbqt/hbqt_qtextblockformat.cpp
  + harbour/contrib/hbqt/hbqt_qtextblockgroup.cpp
  + harbour/contrib/hbqt/hbqt_qtextboundaryfinder.cpp
  + harbour/contrib/hbqt/hbqt_qtextbrowser.cpp
  + harbour/contrib/hbqt/hbqt_qtextcharformat.cpp
  + harbour/contrib/hbqt/hbqt_qtextcursor.cpp
  + harbour/contrib/hbqt/hbqt_qtextdecoder.cpp
  + harbour/contrib/hbqt/hbqt_qtextdocument.cpp
  + harbour/contrib/hbqt/hbqt_qtextdocumentfragment.cpp
  + harbour/contrib/hbqt/hbqt_qtextdocumentwriter.cpp
  + harbour/contrib/hbqt/hbqt_qtextformat.cpp
  + harbour/contrib/hbqt/hbqt_qtextstream.cpp

  * harbour/contrib/hbqt/Makefile_gen

  + harbour/contrib/hbqt/qth/QClipboard.qth
  + harbour/contrib/hbqt/qth/QTextBlock.qth
  + harbour/contrib/hbqt/qth/QTextBlockFormat.qth
  + harbour/contrib/hbqt/qth/QTextBlockGroup.qth
  + harbour/contrib/hbqt/qth/QTextBoundaryFinder.qth
  + harbour/contrib/hbqt/qth/QTextBrowser.qth
  + harbour/contrib/hbqt/qth/QTextCharFormat.qth
  + harbour/contrib/hbqt/qth/QTextCursor.qth
  + harbour/contrib/hbqt/qth/QTextDecoder.qth
  + harbour/contrib/hbqt/qth/QTextDocument.qth
  + harbour/contrib/hbqt/qth/QTextDocumentFragment.qth
  + harbour/contrib/hbqt/qth/QTextDocumentWriter.qth
  + harbour/contrib/hbqt/qth/QTextFormat.qth
  + harbour/contrib/hbqt/qth/QTextStream.qth

  + harbour/contrib/hbqt/tests/demoqt.prg
  + harbour/contrib/hbqt/tests/wvtext.prg
  + harbour/contrib/hbqt/TQTextBlock.prg
  + harbour/contrib/hbqt/TQTextBlockFormat.prg
  + harbour/contrib/hbqt/TQTextBlockGroup.prg
  + harbour/contrib/hbqt/TQTextBoundaryFinder.prg
  + harbour/contrib/hbqt/TQTextBrowser.prg
  + harbour/contrib/hbqt/TQTextCharFormat.prg
  + harbour/contrib/hbqt/TQTextCursor.prg
  + harbour/contrib/hbqt/TQTextDecoder.prg
  + harbour/contrib/hbqt/TQTextDocument.prg
  + harbour/contrib/hbqt/TQTextDocumentFragment.prg
  + harbour/contrib/hbqt/TQTextDocumentWriter.prg
  + harbour/contrib/hbqt/TQTextFormat.prg
  + harbour/contrib/hbqt/TQTextStream.prg

+ Added several new classes, hbqtgen.prg adjusted for
  new definitions, implemented more info in the sources
  but deferred for next commit.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/Makefile_gen
trunk/harbour/contrib/hbqt/generator/hbqtgen.prg
trunk/harbour/contrib/hbqt/generator/qt45.qtp
trunk/harbour/contrib/hbqt/hbqt.h
trunk/harbour/contrib/hbqt/tests/demoqt.prg
trunk/harbour/contrib/hbqt/tests/wvtext.prg

Added Paths:
---
trunk/harbour/contrib/hbqt/TQTextBlock.prg
trunk/harbour/contrib/hbqt/TQTextBlockFormat.prg
trunk/harbour/contrib/hbqt/TQTextBlockGroup.prg
trunk/harbour/contrib/hbqt/TQTextBoundaryFinder.prg
trunk/harbour/contrib/hbqt/TQTextBrowser.prg
trunk/harbour/contrib/hbqt/TQTextCharFormat.prg
trunk/harbour/contrib/hbqt/TQTextCursor.prg
trunk/harbour/contrib/hbqt/TQTextDecoder.prg
trunk/harbour/contrib/hbqt/TQTextDocument.prg
trunk/harbour/contrib/hbqt/TQTextDocumentFragment.prg
trunk/harbour/contrib/hbqt/TQTextDocumentWriter.prg
trunk/harbour/contrib/hbqt/TQTextFormat.prg
trunk/harbour/contrib/hbqt/TQTextStream.prg
trunk/harbour/contrib/hbqt/hbqt_qtextblock.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextblockformat.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextblockgroup.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextboundaryfinder.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextbrowser.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextcharformat.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextcursor.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextdecoder.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextdocument.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextdocumentfragment.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextdocumentwriter.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextformat.cpp
trunk/harbour/contrib/hbqt/hbqt_qtextstream.cpp
trunk/harbour/contrib/hbqt/qth/QClipboard.qth
trunk/harbour/contrib/hbqt/qth/QTextBlock.qth
trunk/harbour/contrib/hbqt/qt

RE: [Harbour] SF.net SVN: harbour-project:[10885] trunk/harbour

[Bisz István]

Because I can contribute in this way to correct the repository.

-Original Message-
From: Massimo Belgrano [mailto:mbelgr...@deltain.it] 
Sent: Sunday, April 19, 2009 1:55 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[10885] trunk/harbour

Why not create contrib library using  hbmk2?
More simple to recompile and maintain
a user will recompile a single contrib without require gnu make

2009/4/19 Bisz István :
> Hi,
>
> The Makefile doesn't generate the gtqtc lib. Maybe the library name is
wrong, could you please review?
> Thanks.
> Regards,
> István
>
> -Original Message-
> From: vouch...@users.sourceforge.net
[mailto:vouch...@users.sourceforge.net]
> Sent: Sunday, April 19, 2009 2:48 AM
> To: harbour@harbour-project.org
> Subject: [Harbour] SF.net SVN: harbour-project:[10885] trunk/harbour
>
> Revision: 10885
>        
 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10885&view=
rev
> Author:   vouchcac
> Date:     2009-04-19 00:48:17 + (Sun, 19 Apr 2009)
>
> Log Message:
> ---
> 2009-04-18 17:41 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
>  * harbour/contrib/gtqtc/Makefile
>    ! Adopted along hbqt/Makefile pattern.
>
>  + harbour/contrib/gtqtc/tests/wvtext.prg
>    + Added harbour/tests/wvtext.prg here also.
>      Change in only HB_GT_QTC_DEFAULT.
>      This facilitates the comparison between GTWVT and GTQTC
>    + Added harbour/tests/tests.ico
>      Used as hb_gtInfo( HB_GTI_ICONFILE, 'tests.ico' )
>
> Modified Paths:
> --
>    trunk/harbour/ChangeLog
>    trunk/harbour/contrib/gtqtc/Makefile
>
> Added Paths:
> ---
>    trunk/harbour/contrib/gtqtc/tests/test.ico
>    trunk/harbour/contrib/gtqtc/tests/wvtext.prg
>
>
> This was sent by the SourceForge.net collaborative development platform,
the world's largest Open Source development site.
>
>
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[10887] trunk/harbour

[Bisz István]

Good question.
Please try:

set HB_CONTRIB_ADDONS=gtqtc

-Original Message-
From: Massimo Belgrano [mailto:mbelgr...@deltain.it] 
Sent: Sunday, April 19, 2009 5:51 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[10887] trunk/harbour

How can be compiled gtqtc?

2009/4/19  :
> Revision: 10887
>        
 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10887&view=
rev
> Author:   vouchcac
> Date:     2009-04-19 13:15:21 + (Sun, 19 Apr 2009)
>
> Log Message:
> ---
> 2009-04-19 06:14 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
>  * harbour/contrib/gtqtc/Makefile
>    ! Adopted along hbqt/Makefile pattern - fix to prev.
>      Thanks Bisz Istvan.
>
> Modified Paths:
> --
>    trunk/harbour/ChangeLog
>    trunk/harbour/contrib/gtqtc/Makefile
>
>
> This was sent by the SourceForge.net collaborative development platform,
the world's largest Open Source development site.
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[13171] trunk/harbour

[Bisz István]

Hi

An another test case with full positive results with latest SVN and Qt 4.6 for 
VS2008. The MinGW with Qt 4.6 and Qt 4.5.3 follows...
hbide, demoxbp and demoqt are executed crash free, so we should concentrate on 
the functional issues from now, I think.
See below the script used for my tests, please tune/comment it:

 @echo PREREQUISITES:
 @echo Installed Qt 4.6 for vs2008 to the default directory: C:/Qt/4.6.0/ 
...
 @echo from: 
http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-vs2008.exe
 @echo Updated c:\download\harbour with the latest SVN
 @pause

 @set HB_WITH_QT=C:/Qt/4.6.0/include
 @set HB_INSTALL_PREFIX=c:\harbour\msvc
 call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86
 @cd c:\downloads\harbour
 @win-make clean install

 @set PATH=%PATH%;C:\harbour\msvc\bin
 @cd c:\downloads\harbour\contrib\hbide
 @hbmk2 -rebuild hbide.hbp -cflag=-MD
 @cd c:\downloads\harbour\contrib\hbxbp\tests
 @hbmk2 -rebuild demoxbp.prg
 @cd c:\downloads\harbour\contrib\hbqt\tests
 @hbmk2 -rebuild demoqt.prg

 @set PATH=%PATH%;C:\Qt\4.6.0\bin
 @cd c:\downloads\harbour\contrib\hbide
 @hbide
 @pause
 @cd c:\downloads\harbour\contrib\hbxbp\tests
 @demoxbp
 @pause
 @cd c:\downloads\harbour\contrib\hbqt\tests
 @demoqt
 @pause

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] SF.net SVN: harbour-project:[13171] trunk/harbour

[Bisz István]

Hi,

>I guess this should either be:
>@win-make clean install HB_USER_CFLAGS=-MD
>OR kept as is, and the trick suggested by Andi could be 
>used when building hbide:
>@hbmk2 -rebuild hbide.hbp -ldflag=-nodefaultlib:MSVCRT.LIB
-ldflag=-defaultlib:LIBCMT.LIB

Thank you Viktor, Andi.

The Andi's solution is less 'intrusive', so see the merged script variant
below with the same very positive results:

 @echo PREREQUISITES:
 @echo Installed Qt 4.6 for vs2008 to the default directory:
C:/Qt/4.6.0/ ...
 @echo from:
http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-vs2008.exe
 @echo Updated c:\download\harbour with the latest SVN
 @pause

 @set HB_WITH_QT=C:/Qt/4.6.0/include
 @set HB_INSTALL_PREFIX=c:\harbour\msvc
 @call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
x86
 @cd c:\downloads\harbour
 @win-make clean install

 @set PATH=%PATH%;C:\harbour\msvc\bin
 @cd c:\downloads\harbour\contrib\hbide
@rem @hbmk2 -rebuild hbide.hbp -cflag=-MD
@rem the above line is commented and replaced by the trick suggested by
Andi:
 @hbmk2 -rebuild hbide.hbp -ldflag=-nodefaultlib:MSVCRT.LIB
-ldflag=-defaultlib:LIBCMT.LIB -info -trace
 @cd c:\downloads\harbour\contrib\hbxbp\tests
 @hbmk2 demoxbp.prg -info -trace
 @cd c:\downloads\harbour\contrib\hbqt\tests
 @hbmk2 demoqt.prg -info -trace

 @set PATH=%PATH%;C:\Qt\4.6.0\bin
 @cd c:\downloads\harbour\contrib\hbide
 @hbide
 @pause
 @cd c:\downloads\harbour\contrib\hbxbp\tests
 @demoxbp
 @pause
 @cd c:\downloads\harbour\contrib\hbqt\tests
 @demoqt
 @pause

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] Error building HbIDE

[Bisz István]

Without having so much time to analyze your details... Please try:
d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -lpsapi 

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Guillermo Varona
Silupú
Sent: 2009. december 10. 14:58
To: harbour@harbour-project.org
Subject: [Harbour] Error building HbIDE

Hi, This is:

C:\harbour\contrib\hbide>d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild 
-LC:\Qt\2009.04\qt\lib
hbmk2: Processing environment options: -compiler=mingw
hbmk2: Compiling Harbour sources...
Harbour 2.0.0beta3 (Rev. 13197)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'hbide.prg'...
Lines 6388, Functions/Procedures 52
Generating C source output to '.hbmk\win\mingw\hbide.c'... Done.
Compiling 'idestylesheets.prg'...
Lines 6620, Functions/Procedures 1
Generating C source output to '.hbmk\win\mingw\idestylesheets.c'... Done.
Compiling 'idetags.prg'...
Lines 9786, Functions/Procedures 4
Generating C source output to '.hbmk\win\mingw\idetags.c'... Done.
Compiling 'idemisc.prg'...
Lines 13142, Functions/Procedures 22
Generating C source output to '.hbmk\win\mingw\idemisc.c'... Done.
Compiling 'ideactions.prg'...
Lines 16030, Functions/Procedures 2
Generating C source output to '.hbmk\win\mingw\ideactions.c'... Done.
hbmk2: Compiling...
hbmk2: Linking... hbide.exe
d:/hrbMinGW/lib/libhbqt.a(hbqt_base.o):hbqt_base.cpp:(.text+0xeb): 
undefined ref
erence to `getprocessmemoryi...@12'
d:/hrbMinGW/lib/libhbqt.a(hbqt_base.o):hbqt_base.cpp:(.text+0x17b): 
undefined reference to `getprocessmemoryi...@12'
collect2: ld returned 1 exit status
hbmk2: Error: Running linker. 1
gcc.exe .hbmk\win\mingw\hbide.o .hbmk\win\mingw\idestylesheets.o 
.hbmk\win\mingw
\idetags.o .hbmk\win\mingw\idemisc.o .hbmk\win\mingw\ideactions.o 
.hbmk\win\ming
w\ideparseexpr.o .hbmk\win\mingw\_hbmkaut.o-mwindows 
-Wl,--start-group -lhbx
bp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lversion -lshlwapi 
-lQtCore4 -lQtG
ui4 -lQtNetwork4 -lQtUiTools -lsupc++ -lhbextern -lhbdebug -lhbvm 
-lhbrtl -lhbla
ng -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd 
-lhbuddall
-lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix 
-lhbmacro
  -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 
-lws2_32 -lwi
nspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr 
-lwinmm -
lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib  -Wl,--end-group 
-ohbide.e
xe -Ld:/hrbMinGW/lib -L/../lib -LC:/Qt/2009.04/qt/lib

C:\harbour\contrib\hbide>

Any TIP?

TIA

BestRegards
GVS

___
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] Re: Error building HbIDE

[Bisz István]

You're welcome. But see last commit no is default thanks to Viktor.

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Guillermo Varona
Silupú
Sent: 2009. december 10. 15:46
To: harbour@harbour-project.org
Subject: [Harbour] Re: Error building HbIDE

Bisz István escribió:
> Without having so much time to analyze your details... Please try:
> d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -lpsapi 

Thanks very much, now work ok.

BestRegards
GVS

___
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] Re: Error building HbIDE

[Bisz István]

sorry for my typing: no -> now...

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2009. december 10. 15:47
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] Re: Error building HbIDE

You're welcome. But see last commit no is default thanks to Viktor.

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Guillermo Varona
Silupú
Sent: 2009. december 10. 15:46
To: harbour@harbour-project.org
Subject: [Harbour] Re: Error building HbIDE

Bisz István escribió:
> Without having so much time to analyze your details... Please try:
> d:\hrbmingw\bin\hbmk2 hbide.hbp -rebuild -lpsapi 

Thanks very much, now work ok.

BestRegards
GVS

___
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] SF.net SVN: harbour-project:[13171] trunk/harbour

[Bisz István]

Hi Viktor,

>Is there any final result for the three different 
>memory handling modes?

Yes, this is the final structure, as the handling mode should be dynamic,
please consult the Qt documents. Is in specified cases is recommended to use
the "delete later" feature what is the default for the actual interface
implementation. After consulting the actual Qt documentation and discussions
on the adequate sites please live it at is, is a conscious decision from my
side, to offer the flexibility to adopt the existing and future decisions of
the Qt developers.

> IMO we should only leave one, the one which works 
> the most efficiently and without leaks.

>Is it time to make the decision yet?

This is not black or white issue, it's not a race situation here, studying
the Qt documentations, we need a dynamic approach here. In some situation
the best solution can be different, so please close this issue, I
intentionally put that things in the code, maybe we are less informed, but
studying the Qt documents...
 
But as a final conclusion, WE ARE NOT FACING WITH MEMO LEAK ISSUES regarding
the Qt interface automatically generated. The problem is with our
measurement instruments! We will need help here to demonstrate it, if is the
case. The actual Windows implementation is not adequate to decide the memory
"consumption" as the windows internal are so complicated. I tried to tune
somehow the Pritpals algorithms but without success after studying some
sites, sorry.

So my general feeling is that the 'memory' problem is solved by the
automatic generated code! For these things demonstration we have to work
hardly.

I stopped temporally my thinking...


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] SF.net SVN: harbour-project:[13171] trunk/harbour

[Bisz István]

Hi Viktor,

>Thank you for the explanation.

>Probably some short docs would be nice to see the difference between these
methods though, as without it, it's very difficult for users to make use of
this feature or decide whether
 > yit's needed at all for real Harbour QT apps/users.

Sorry, I can't help here, the destruction method targets just the next level
like hbxbp and similar in the future, who knows...

>For the most part this is true, however (and I wonder if anyone 
>reads my mails on this list :( ):

>- There are some inherited/HBQT-only classes which are not equipped 
>  with automatic GC collection.
>- Some resources still need manual deallocation (like mutex, slots 
y  and events, per app and/or per thread)

>Making a little mistake on the .prg-level can easily cause a leak, 
>and there are signs that such leaks are present even in current .prg 
>code (posted about it already: MyMainWindow in HBXBP).

Ok, Viktor, this is not just our problem, just consult the Qt sites, but
don't forget that we are using an live SW now.

>IMO above issues should be inspected, and a generic 
>solution developed to cover them and avoid repeating 
>them in the future.

I completely agree with you, but please define the solution taking into
consideration that the target is so complex...
If somebody has some ideas how to handle this issue is welcome...

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] SF.net SVN: harbour-project:[13171] trunk/harbour

[Bisz István]

Hi

See below the test cases producing positive results with latest SVN and:
1. tdm-mingw.4.4.1 and Qt 4.5.3 for MinGW
2. tdm-mingw.4.4.1 and Qt 4.6.0 for MinGW
3. VS2008 and Qt 4.6 for VS2008 

hbide, demoxbp and demoqt are executed crash free finally in the above listed 
test cases.

Regarding point 1. and 2. a very old problem regarding the demoqt crash on exit 
in default build mode is clarified.

See GDB output with Application Verifier enabled:

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 5544.0x10ac]
warning: Page heap: pid 0x15A8: page heap enabled with flags 0x3.

warning: AVRF: demoqt.exe: pid 0x15A8: flags 0x80443027: application 
verifier enabled

[New thread 5544.0x142c]
[New thread 5544.0x167c]
[New thread 5544.0x1648]
Error: dll starting at 0x7169 not found.
Error: dll starting at 0xd00 not found.
warning: Lowest section in C:\Windows\system32\normaliz.dll is .text at 
00401000

Error: dll starting at 0x70dd not found.
BFD: C:\Windows\system32\SLC.dll: Warning: Ignoring section flag 
IMAGE_SCN_MEM_N
OT_PAGED in section .reloc
BFD: C:\Windows\system32\SLC.dll: Warning: Ignoring section flag 
IMAGE_SCN_MEM_N
OT_PAGED in section .reloc
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
(gdb) 

The crash is produced by:
warning: HEAP[demoqt.exe]:
warning: Invalid address specified to RtlSizeHeap( 003B, 01A99C08 )

The explanation of this event is, as I understand correctly, that malloc and 
free should be redefined to eliminate a conflict with the qt dll-s. 
This redefinition in fm.c is conditioned actually HB_FM_DLMT_ALLOC or 
USE_DL_PREFIX definition (An another solution is HB_FM_WIN_ALLOC with HB_OS_WIN 
not analyzed by me):

#  if defined( HB_FM_DLMT_ALLOC )
# define malloc( n ) mspace_malloc( hb_mspace(), ( n ) )
# define realloc( p, n ) mspace_realloc( NULL, ( p ), ( n ) )
# define free( p )   mspace_free( NULL, ( p ) )
#  elif defined( USE_DL_PREFIX )
# define malloc( n ) dlmalloc( ( n ) )
# define realloc( p, n ) dlrealloc( ( p ), ( n ) )
# define free( p )   dlfree( ( p ) )
#  endif

The first (HB_FM_DLMT_ALLOC) definition generally is defined in MT mode. The 
second (USE_DL_PREFIX) as we can see:

#  if defined( __BORLANDC__ )

...

#  elif defined( __WATCOMC__ )

...

# if !defined( USE_DL_PREFIX ) && !defined( HB_FM_DLMT_ALLOC )
#define USE_DL_PREFIX
# endif
#  elif defined( _MSC_VER )
# if !defined( USE_DL_PREFIX ) && !defined( HB_FM_DLMT_ALLOC )
#define USE_DL_PREFIX
# endif
...

#  endif
#  if defined( __cplusplus ) && ! defined( USE_DL_PREFIX )
# define USE_DL_PREFIX
#  endif
#  include "dlmalloc.c"

...

is not defined in ST and MinGW C mode. This sequences analysis explains my 
tests: The mingw build of the demoqt in C mode crashes on the first delete 
operator.
 
The solution is @set HB_USER_CFLAGS=-DUSE_DL_PREFIX.
Hopefully my conclusion is correct, but take into consideration that this is 
just an experiment and not "theory".

See below the script used for my tests:

 @echo PREREQUISITES:
 @echo 1) Installed Qt 4.5.3 for MinGW to the directory: C:/Qt/4.5.3/ ...
 @echo from: 
http://get.qt.nokia.com/qt/source/qt-win-opensource-4.5.3-mingw.exe
 @echo 2) Installed tdm-mingw.4.4.1 to C:\devl\MinGWtdm\ ...
 @echo from: 
http://sunet.dl.sourceforge.net/project/tdm-gcc/TDM-MinGW%20Installer/1.908.0/tdm-mingw-1.908.0-4.4.1-2.exe
 @echo with dual SJLJ and Dwarf-2 installation into the same directory
 @echo Use just the installer without manual unzipping...  
 @echo 3) Updated c:\download\harbour with the latest SVN
 @pause

 @set HB_WITH_QT=C:/Qt/4.5.3/include
 @set HB_COMPILER=mingw
 @set HB_INSTALL_PREFIX=c:\harbour\mingw_4.5.3
 @set PATH=%PATH%;C:\devl\MinGWtdm\bin
 @cd c:\downloads\harbour

 @set HB_USER_CFLAGS=-DUSE_DL_PREFIX

 @win-make clean ins

RE: [Harbour] SF.net SVN: harbour-project:[13171] trunk/harbour

[Bisz István]

Hi Massimo,

Maybe with the last release is not the case, but I had some problems with
'\' in include...
With this trick, just hbqt generates debug info, or you have an advise how
to restrict the debug setting to the hbqt libraries.
The flush force setting ensures that if a crash occurs the all previous
debug lines, just buffered, are written in the log file. 

Best regards,
István

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Massimo Belgrano
Sent: 2009. december 12. 23:08
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13171] trunk/harbour

Hi István
Thanks for share your experiences?
Follow my question

2009/12/12 Bisz István :
> 
>
>     @echo PREREQUISITES:
>     @echo Installed Qt 4.6 for vs2008 to the default directory:
C:/Qt/4.6.0/ ...
>     @echo from:
http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-vs2008.exe
>     @echo Updated c:\download\harbour with the latest SVN
>     @pause
>
>     @set HB_WITH_QT=C:/Qt/4.6.0/include
Why not C:\Qt\4.6.0\include like other
>     @set HB_INSTALL_PREFIX=c:\harbour\msvc
>     @call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
x86
>     @cd c:\downloads\harbour
>     @win-make clean install
Here first make

>     @set HB_USER_CFLAGS=-DHB_TR_LEVEL_DEBUG
>     @set HB_USER_PRGFLAGS=-D__HB_DEBUG__
>     @cd c:\downloads\harbour\contrib\hbqt
>     @c:\downloads\harbour\win-make clean install
Why two execution of win-make clean install?

>
>     @set PATH=%PATH%;C:\harbour\msvc\bin
>     @cd c:\downloads\harbour\contrib\hbide
>     @hbmk2 -rebuild hbide.hbp
>     @cd c:\downloads\harbour\contrib\hbxbp\tests
>     @hbmk2 demoxbp.prg
>     @cd c:\downloads\harbour\contrib\hbqt\tests
>     @hbmk2 demoqt.prg
>
>     @set PATH=%PATH%;C:\Qt\4.6.0\bin
>     @set HB_TR_LEVEL=HB_TR_DEBUG
>     @set HB_TR_FLUSH=1
Why need prev
>     @cd c:\downloads\harbour\contrib\hbide
>     @hbide 2>c:\harbour\hbide.trace.log
>     @pause
>     @cd c:\downloads\harbour\contrib\hbxbp\tests
>     @demoxbp 2>c:\harbour\demoxbp.trace.log
>     @pause
>     @cd c:\downloads\harbour\contrib\hbqt\tests
>     @demoqt 2>c:\harbour\demoqt.trace.log
>     @pause
>
> Best regards,


-- 
Massimo Belgrano
___
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] SF.net SVN: harbour-project:[13171] trunk/harbour

[Bisz István]

> How can be done either SLLJ and Dwarf-2?
> The installer allow me only one

The installer should be started two times indicating the same installation
directory, first executing the default SJLJ and second selecting the
Dwarf-2.


___
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

[Bisz István]

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

RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes

[Bisz István]

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

[Bisz István]

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: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes

[Bisz István]

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: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes

[Bisz István]

>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

[Bisz István]

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

[Bisz István]

> 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] Release notes/questions

[Bisz István]

Hi,

The Harbour 2.0 should implement just the latest  Qt 4.5 patch release
(4.5.3) interface, the Qt4.6 is the next year play space.

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] Window Main X Window Modal X HBQT

[Bisz István]

Please include it in qt test...

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Marcos Gambeta
Sent: 2009. december 17. 19:18
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] Window Main X Window Modal X HBQT

PCToledo escreveu:
> Someone could send a small example of how to create a Window Main and open
> it in a Window Modal?

Your sample with a login dialog:

[code]
/*--*/
#include "hbqt.ch"
#include "common.ch"

#define QT_EVE_TRIGGERED_B   "triggered(bool)"

STATIC oApplication

/*--*/
INIT PROCEDURE Qt_Start()
oApplication := QApplication():new()
RETURN

EXIT PROCEDURE Qt_End()
oApplication:quit()
RETURN

Procedure Main()

Local oMainWindow, oStatusBar, oStatusTit, oMenuBar, oMenuFile, oMB

oMainWindow := QMainWindow():New()

oMainWindow:setMouseTracking( .t. )
oMainWindow:SetWindowTitle("Program title")

oStatusBar := QStatusBar():new(QT_PTROF(oMainWindow))

oStatusTit := QLabel():new()
oStatusTit:setText(" PCToledo Sistemas - supo...@pctoledo.com.br")
oStatusTit:setMinimumSize(oStatusTit:sizeHint())

oStatusBar:addWidget(QT_PTROF(oStatusTit),1)

oMainWindow:setStatusBar( QT_PTROF(oStatusBar) )
oStatusBar:setSizeGripEnabled(.f.)

oMenuBar := QMenuBar():new()
oMenuBar:resize( oMainWindow:width(), 25 )

oMenuFile := QMenu():new()
oMenuFile:setTitle("&File")

Qt_Connect_Signal( oMenuFile:AddAction("&Exit"), QT_EVE_TRIGGERED_B, 
{||oMainWindow:close() })
oMenuBar:addMenu( QT_PTROF( oMenuFile ) )

oMainWindow:setMenuBar( QT_PTROF( oMenuBar ) )

IF PassWord(oMainWindow)
  //valid password
   oMainWindow:showMaximized()
   oApplication:Exec()
ELSE
  //Invalid Password
  oMB := QMessageBox():new()
  oMB:setInformativeText( "Invalid user or password" )
  oMB:setWindowTitle( "Login" )
  oMB:exec()
ENDIF

//oMainWindow:showMaximized()

//oApplication:Exec()

Return

STATIC FUNCTION PassWord()
//Local Ret:=0
Local oDialog
Local oFormLayout
Local oLabelUser
Local oLineEditUser
Local oLabelPassword
Local oLineEditPassword
Local oButtonOk
Local r

oDialog := QDialog():New()
oDialog:setWindowTitle("Login")
oDialog:resize(210,130)
oFormLayout := QFormLayout():New(QT_PTROF( oDialog ))
oLabelUser := QLabel():New()
oLabelUser:setText("User")
oLineEditUser := QLineEdit():New()
oLabelPassword := QLabel():New()
oLabelPassword:setText("Password")
oLineEditPassWord := QLineEdit():New()
oLineEditPassWord:setEchoMode(2)
oFormLayout:addRow( QT_PTROF(oLabelUser), QT_PTROF(oLineEditUser) )
oFormLayout:addRow( QT_PTROF(oLabelPassword), 
QT_PTROF(oLineEditPassword) )
oButtonOk := QPushButton():New(QT_PTROF( oDialog ))
oButtonOk:setText("OK")
oButtonOk:move(100,80)
Qt_Connect_Signal( QT_PTROF(oButtonOk), "clicked()", 
{||IIF(oLineEditUser:text()=="user".and.oLineEditPassword:text()=="password"
,oDialog:done(1),oDialog:done(0)) 
})

r := oDialog:exec()

//Return (Ret)
Return IIF(r==1,.t.,.f.)
[/code]

Take some time to study the classes QDialog and QFormLayout (very useful).


-- 
Regards,
Marcos Antonio Gambeta
___
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] Release notes/questions

[Bisz István]

> Okay. The only small difference that I won't install 
> 4.5.3. The main reason is that it's almost nowhere 
> advertised, so users are much likely to stumble upon 
> 4.5.2.

Maybe this is or problem...

> Anyhow I feel that HBQT is still a work in progress, 
> and for this purpose it really doesn't matter yet 
> what 4.x version we use. We're not yet close to 
> exploiting the limits of the QT framework as far as 
>I can see.

?
I am not sure that I cleanly realized this info. We just use the latest Qt
4.5, as we planned.

Best regards,
István


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: Re[Harbour] lease notes/questions

[Bisz István]

Hi Viktor,

> If someone has a link for plain standard 4.5.2 binary 
> pkg previously available from QT homepage, pls write 
>it.

Please try these links:

http://get.qt.nokia.com/qt/source/qt-win-opensource-4.5.3-mingw.exe
or
http://get.qt.nokia.com/qt/source/qt-win-opensource-4.5.2-mingw.exe

Preferable the first one.

Best regards,
István


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: Re[Harbour] lease notes/questions

[Bisz István]

Hi Viktor,

> Do you know whether DWARF-2 MINGW can be used with 4.5.x?

No, we should use the DWARF-2 MINGW just for 4.6.0 and probably upper.

The explication is that they (Qt 4.6 developers) switched to MinGW with GCC
4.4.0. The MinGw developers decided to support in GCC 4.4.0 release, and
probably upper, just DWARF-2 rewinding. 

Best regards,
István


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: Re[Harbour] lease notes/questions

[Bisz István]

The Fedora 12 current release contains Qt 4.5.3. As we can see in the Fedora
build-system the Qt 4.6 is included just in the upcoming F13 with 2010.05.11
release date.
This the current status and I have no information about the future Qt
versions integration philosophy.
 
Best regards,
István
 

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Lorenzo Fiorini
Sent: 2009. december 18. 9:43
To: Harbour Project Main Developer List.
Subject: Re: Re[Harbour] lease notes/questions

On Fri, Dec 18, 2009 at 1:27 AM, Viktor Szakáts 
wrote:

> Wherever Nokia put that on their site. Last week
> 4.5.2 was available, now it isn't anymore. Or can't
> find it.

Here there are the previous versions: ftp://ftp.qt.nokia.com/qtsdk/

To avoid extra noise, I think we should state which is the one
"supported" for 2.0.

Since we don't have control of the distros' QT version, I think we
should support also Linux packages from qt site.

best regards,
Lorenzo
___
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] Mary Christmas

[Bisz István]

Merry Christmas to everyone and congratulations for the great job!

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 24. 15:48
To: Harbour Project Main Developer List.
Subject: [Harbour] Mary Christmas

Hi All,

I would like to wish all of you Mary Christmas !!!

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] Re: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c

[Bisz István]

Hi Viktor,

This solution strips the trailing isspace characters from the debug info and
inserts the necessary CR/LF for windbg, not more.
Maybe we can define here a lot of similar solutions for the same thing.

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 27. 19:27
To: Harbour Project Main Developer List.
Subject: [Harbour] Re: SF.net SVN: harbour-project:[13399]
trunk/harbour/src/common/hbtrace.c

Hi Istvan,

> +  /*
> +   *  sizeof( buffer2 ) - 3 is room for CR/LF/NUL
> +   */
>   if( proc )
> - hb_snprintf( buffer2, sizeof( buffer2 ), "%s:%d:%s() %s %s",
> -  file, line, proc, pszLevel, buffer1 );
> + n = hb_snprintf( buffer2, sizeof( buffer2 ) - 3, "%s:%d:%s() %s
%s",
> +  file, line, proc, pszLevel, buffer1 );
>   else
> - hb_snprintf( buffer2, sizeof( buffer2 ), "%s:%d: %s %s",
> -  file, line, pszLevel, buffer1 );
> + n = hb_snprintf( buffer2, sizeof( buffer2 ) - 3, "%s:%d: %s %s",
> +  file, line, pszLevel, buffer1 );
> 
> +  /*
> +   *  Normalize buffer2 with ending CR/LF/NUL
> +   */
> +  p = buffer2;
> +  p += (n < 0) ? sizeof( buffer2 ) - 3 : n;
> +  while ( p > buffer2  &&  isspace( p[-1] ) )
> +  {
> + *--p = '\0';
> +  }
> +  *p++ = '\r';
> +  *p++ = '\n';
> +  *p   = '\0';
> +

Maybe I'm missing something but isn't hb_snprintf() _always_ 
closing string with a zero? If not, we have serious security 
problems in hundreds of places in Harbour.

If this is the case, we should rather fix hb_snprintf(), 
than this one specific call of it.

Also, shouldn't \r \n simply added to printf mask string?

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: [Harbour] Re: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c

[Bisz István]

Hi Viktor,

> Overall I'm not sure this function should alter passed trace string in any
ways.
It can easily checked by reverting the change and trying to debug with
windbg, as I know the 'official' GUI debugger.

> As for the anti-reentrance logic, it probably needs to be 
> changed to mutexes, as in ST I can't see any way it can be 
> called in recursive fashion, and in MT current solution will 
> just delay problems by causing lost trace messages.
The original logic generates "stack overflow events" for example:
1. "   HB_TRACE( HB_TR_DEBUG, ( "  new_QApplication
%i B %i KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );" 
If fm.c and QApplication.cpp is build with -DHB_TR_LEVEL_DEBUG.
2. If fm.c is requested with -DHB_TR_LEVEL_DEBUG. The HB_TCHAR_CONVTO macro
calls indirectly HB_TRACE, generating in this way the mentioned stack
overflow. Fortunately debugged with windbg.
3. Generally we should not call inside the HB_TRACE a call to itself.

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 27. 22:40
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] Re: SF.net SVN: harbour-project:[13399]
trunk/harbour/src/common/hbtrace.c

Hi,

> Hi Viktor,
> 
> This solution strips the trailing isspace characters from the debug info
and
> inserts the necessary CR/LF for windbg, not more.
> Maybe we can define here a lot of similar solutions for the same thing.

One problem with this is that it's now implemented as a 
Windows-only solution. (BTW I don't really understand why 
Windows debugging needs are _always_ different from any 
other platforms...). Overall I'm not sure this function 
should alter passed trace string in any ways.

Proper fix IMO is to change those trace calls which pass 
ending spaces. There is probably not too many of them.

As for the anti-reentrance logic, it probably needs to be 
changed to mutexes, as in ST I can't see any way it can be 
called in recursive fashion, and in MT current solution will 
just delay problems by causing lost trace messages.

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: [Harbour] Re: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c

[Bisz István]

Hi Viktor,

> I'd appreciate if you could describe it, as I don't have such 
> official debugger on my system, I used DbgView() for tests.

The windbg in a component of "Microsoft Windows SDK for Windows 7 and .NET
Framework 3.5 SP1" / "Debugging tools for Windows".
Dbgview is just a very useful viewer. I tested it and I cannot see any
differences comparing with the previous solution without CR/LF insertion.
If it is necessary we can generate here a flexible solution with and without
CR/LF, selectable by the existing HB_TR_WINOUT envvar. 

> If extra line ending (/r or /n or both) is required for windbg, 
> it's easy to add it to printf() calls, although I'm still not 
> sure why ending space trimming is required, or in which calls 
> does this exactly causes problems.

An any optimized solution is welcome, with the original solution the debug
messages are shown without line-feeds.

> You're right, now it's clear. In this case the solution is to replace 
> HB_TCHAR_* macros with something native. I'll try to do it.

We need here a general solution taking into consideration the all possible
situations when HB_TRACE is called indirectly in HB_TRACE.

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: SF.net SVN: harbour-project:[13399] trunk/harbour/src/common/hbtrace.c

[Bisz István]

Hi Xavi,

> Sorry but ... What this issue has to do with this code?

No, the mentioned code serves just WinDbg, I tested it with DbgView too. But
after the latest commits it's obsolete.

> Please, to which I can understand and sorry for my bad English.
> Do you saying that windbg generate issue because the string does not end
with CR/LF.

No, you misunderstood me, sorry. The mentioned crash is related to an
another patch, trying to solve the case when inside a HB_TRACE an another
HB_TRACE is activated.
 
Best regards,
István

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Xavi
Sent: 2009. december 28. 1:18
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] Re: SF.net SVN: harbour-project:[13399]
trunk/harbour/src/common/hbtrace.c

El 27/12/2009 23:12, Bisz István escribió:
> 2. If fm.c is requested with -DHB_TR_LEVEL_DEBUG. The HB_TCHAR_CONVTO
macro
> calls indirectly HB_TRACE, generating in this way the mentioned stack
> overflow. Fortunately debugged with windbg.

Sorry but ... What this issue has to do with this code?
...
   /*
*  Normalize buffer2 with ending CR/LF/NUL
*/
   p = buffer2;
   p += (n < 0) ? sizeof( buffer2 ) - 3 : n;
   while ( p > buffer2  &&  isspace( p[-1] ) )
   {
  *--p = '\0';
   }
   *p++ = '\r';
   *p++ = '\n';
   *p   = '\0';
...

> If it is necessary we can generate here a flexible solution with and
without
> CR/LF, selectable by the existing HB_TR_WINOUT envvar.

Please, to which I can understand and sorry for my bad English.
Do you saying that windbg generate issue because the string does not end
with CR/LF.

TIA,
-- 
Xavi

El 28/12/2009 0:43, Bisz István escribió:
> Hi Viktor,
>
>> I'd appreciate if you could describe it, as I don't have such
>> official debugger on my system, I used DbgView() for tests.
>
> The windbg in a component of "Microsoft Windows SDK for Windows 7 and .NET
> Framework 3.5 SP1" / "Debugging tools for Windows".
> Dbgview is just a very useful viewer. I tested it and I cannot see any
> differences comparing with the previous solution without CR/LF insertion.
> If it is necessary we can generate here a flexible solution with and
without
> CR/LF, selectable by the existing HB_TR_WINOUT envvar.
>
>> If extra line ending (/r or /n or both) is required for windbg,
>> it's easy to add it to printf() calls, although I'm still not
>> sure why ending space trimming is required, or in which calls
>> does this exactly causes problems.
>
> An any optimized solution is welcome, with the original solution the debug
> messages are shown without line-feeds.
>
>> You're right, now it's clear. In this case the solution is to replace
>> HB_TCHAR_* macros with something native. I'll try to do it.
>
> We need here a general solution taking into consideration the all possible
> situations when HB_TRACE is called indirectly in HB_TRACE.
>
> Best regards,
> István
>
___
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] SF.net SVN: harbour-project:[13402] trunk/harbour

[Bisz István]

Hi Viktor,

 

Maybe reverting the hack for non win code too is useful temporarily, until the 
final solution designing. Maybe an RTE mechanism should be defined in non win 
part to avoid the reentrant call of the trace engine.

This will signal the trap residing in the following code:

   HB_TRACE( HB_TR_DEBUG, ( "  new_QApplication%i B %i 
KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );
As I mentioned in one of my previous mail, the hb_xquery() calls the trace 
engine too, generating undesired behavior.

 

The va_end() issue:

 

Please analyze the following code snippets:

…

   if( s_enabled && level <= hb_tr_level() )
   {
  va_list ap;
  va_start( ap, fmt );
  hb_tracelog_( level, file, line, proc, fmt, ap );
  va_end( ap );
   }
…

   if( s_enabled )
   {
  va_list ap;
  va_start( ap, fmt );
  hb_tracelog_( hb_tr_level_, hb_tr_file_, hb_tr_line_, NULL, fmt, ap );
  va_end( ap );
…

So we can leave the:

   /*
* Print the name and arguments for the function.
*/
   vfprintf( s_fp, fmt, ap );

   /* if( s_winout ) this is not necessary here */ 
   /* TOFIX: va_end() is _required_ here according to all available 
documentation. */
   /* va_end( ap ); Generates access violation in the subsequent hb_vsnprintf */



without va_end();

 

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] SF.net SVN: harbour-project:[13415] trunk/harbour

[Bisz István]

Hi,

> Please test these modifications in real MS-Windows systems.

Clean and nice as always, thank you Przemek!

After testing with and without -DHB_TR_LEVEL_DEBUG cflags, it works as it is 
expected.

In my test case the QApplication.cpp: line 212-214 contains:
 
   HB_TRACE( HB_TR_DEBUG, ( "  new_QApplication%i B %i 
KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );
   HB_TRACE( HB_TR_DEBUG, ( "0=%i 0=%i 2=%i 3=%i 4=%i 5=%i 6=%i 7=%i 8=%i 9=%i 
A=%i B=%i C=%i D=%i E=%i F=%i",   0,1,2,3,4,5,6,7,8,9,10,11,12,12,14,15 ) );
   HB_TRACE( HB_TR_DEBUG, ( "0=%i 0=%i 2=%i 3=%i 4=%i 5=%i 6=%i 7=%i 8=%i 9=%i 
A=%i B=%i C=%i D=%i E=%i F=%i 10=%i", 0,1,2,3,4,5,6,7,8,9,10,11,12,12,14,15,16 
) );

and DbgView shows with HB_TR_LEVEL_DEBUG defined in fm.c:
 
0006224617:42:34.462[4612] c:\downloads\harbour\src\vm\fm.c:1187: 
HB_TR_DEBUG hb_xquery(1001)
0006224717:42:34.462[4612] c:\downloads\harbour\src\vm\fm.c:1187: 
(???)   new_QApplication0 B 3100 KB
0006224817:42:34.462[4612] QApplication.cpp:213: HB_TR_DEBUG 0=0 
0=1 2=2 3=3 4=4 5=5 6=6 7=7 8=8 9=9 A=10 B=11 C=12 D=12 E=14 F=15
0006224917:42:34.462[4612] QApplication.cpp:214: HB_TR_DEBUG more 
then 16 parameters in message '0=%i 0=%i 2=%i 3=%i 4=%i 5=%i 6=%i 7=%i 8=%i 
9=%i A=%i B=%i C=%i D=%i E=%i F=%i 10=%i'

My test results:

1. Analyzing the output produced by the line 212 we can see that the file, line 
and level info is altered. Maybe is useful to send here the original info 
instead of hb_xquery trace location.
2. The insertion of the hb_xtraced function in nortl.c it was necessary to 
build harbour with HB_TR_LEVEL_DEBUG defined:

HB_BOOL hb_xtraced( void )
{
   return HB_FALSE;
}

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] HAPPY NEW YEAR !!!

[Bisz István]

HAPPY NEW YEAR !

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 31. 19:23
To: Harbour Project Main Developer List.
Subject: [Harbour] HAPPY NEW YEAR !!!

Hi All,

I want to wish all of you HAPPY NEW YEAR !!!

It's time to turn off the computer.
My next message will be in year 2010 :-)

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] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

Hi Viktor,

It is a summary of a long way hunting/debugging, so these short
sentences/fragments are not adequate to describe the fix. But, as I see this
is an usual way for fixing, without so much details.

Please test it in MinGW environment, should fix some errors mainly in object
handlings regarding the Heap managements.

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: 2010. január 2. 22:58
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

Hi Istvan,

> Log Message:
> ---
> 2009-01-02 21:59 UTC+0100 Istvan Bisz (istvan.bisz/at/t-online.hu)
>  * /src/vm/fm.c
>* Not adequate defitions of the subsequent CRT functions for the MinGW
implemetations:
>  #ifndef USE_DL_PREFIX
>  #define dlcalloc   calloc 
>  #define dlfree free
>  #define dlmalloc   malloc
>  ...
>  #endif /* USE_DL_PREFIX */
>  The malloc/free CRT functions should'nt be redefined in this way.

Just a general note: It would be nice to see in your 
change descriptions what is actually fixed. I mean what 
was the observed error before the fix.

Now I can't even test it, as it always worked for me 
even so far, don't know how to verify the improvement.

>* The mesage: "Warning, memory allocated but not released..." is sent
on request (//INFO cmdarg).

But this way the text of the message is misleading.
IMO it should only be displayed if there _are_ unreleased blocks.
Saying "Warning, memory allocated but not released: 0 blocks" looks 
like a display bug.

IMO it was good as it was, or I'm missing something.

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: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

Hi Viktor,

> I'd like to kindly ask you to elaborate more.

With the previous, default build, way of the Heap managements, the HVM for
MinGW tried to replace the CRT functions with its own malloc, free, etc. 
This is a completely wrong solution in this context, is too weak.

> How about the other change?


Total memory allocated: 2251241 bytes (29215 block(s))
Warning, memory allocated but not released: 0 bytes (0 block(s))

It is the message (with HB_USER_CFLAGS=-DHB_FM_STATISTICS), when the all
allocated blocks are released perfectly, if it is not adequate please change
it.

Note: Is the ending message now for hbide and demoxbp.

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] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

>Maybe MinGW was the same, but it didn't report it?

Personally, I reported it several times, sorry.

> Currently above msg will also appear when not compiled 
> with fmstat. I'll commit a fix.
 
OK.

> Plus we're not using the official C++ allocation override 
> for HBQT yet, which may be a problem. What do you think?

Could you please more explicit, regarding this issue.

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: 2010. január 3. 0:10
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour


On 2010 Jan 2, at 23:49, Bisz István wrote:

> Hi Viktor,
> 
>> I'd like to kindly ask you to elaborate more.
> 
> With the previous, default build, way of the Heap managements, the HVM for
> MinGW tried to replace the CRT functions with its own malloc, free, etc. 
> This is a completely wrong solution in this context, is too weak.

I hope Przemek can comment on it. I still can't 
see the real reason here. We do it for some compilers 
and we don't do it for others. For MSVC, without 
this trick it gave memory errors on exit so it was 
clearly apparent. Maybe MinGW was the same, but it 
didn't report it?

>> How about the other change?
> 
> 
> Total memory allocated: 2251241 bytes (29215 block(s))
> Warning, memory allocated but not released: 0 bytes (0 block(s))

Currently above msg will also appear when not compiled 
with fmstat. I'll commit a fix.

> It is the message (with HB_USER_CFLAGS=-DHB_FM_STATISTICS), when the all
> allocated blocks are released perfectly, if it is not adequate please
change
> it.
> 
> Note: Is the ending message now for hbide and demoxbp.

There are still two HBQT TOFIXes where leak is only prevented 
by explicit .prg calls.

Plus we're not using the official C++ allocation override 
for HBQT yet, which may be a problem. What do you think?

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: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

OK, these are just the global operator redefinitions, does not affect the Qt
interface deletes. We can comment them.

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts
Sent: 2010. január 3. 0:31
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

On 2010 Jan 3, at 00:18, Bisz István wrote:

>> Maybe MinGW was the same, but it didn't report it?
> 
> Personally, I reported it several times, sorry.

Until I can see a way to replicating it on any 
system, to me the matter stays shady.

>> Currently above msg will also appear when not compiled 
>> with fmstat. I'll commit a fix.
> 
> OK.
> 
>> Plus we're not using the official C++ allocation override 
>> for HBQT yet, which may be a problem. What do you think?
> 
> Could you please more explicit, regarding this issue.

You're testing HBQT unreleased memory as reported by 
our memory manager, but C++ mode isn't currently fully 
(or at all?) setup to use our own memory allocation 
functions.

Here is the complete set which needs to be overridden 
as per QT documentation:

---
#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 );
}
---

I've committed it to fm.c.

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: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

Hi Mindaugas,

Yes, the zeroes are important, but Viktor redefines these printout to a more
precise ones.

Best regards,
István
   
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Mindaugas
Kavaliauskas
Sent: 2010. január 3. 0:37
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

Hi,


Bisz István wrote:
> Total memory allocated: 2251241 bytes (29215 block(s))
> Warning, memory allocated but not released: 0 bytes (0 block(s))

So, let's print a single line joined message:

Total memory allocated: 2251241 bytes (29215 block(s)), not released: 0 
bytes (0 block(s))

if these zeros are important, otherwise message looks redundant.


Regards,
Mindaugas
___
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] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

>Probably that's the reason Istvan added it.

Yes, it was a missing of the missed info.


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

>What is the way to force our allocation functions to be 
>used by QT C++ new/delete operators?

>Without this, any fm.c leak measurement is pointless 
>for QT subsystem, as our fmstat modules is just not used 
>at all by it.

I can see hacks just for the static builds, but it is a hard way, in any
case...



___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

An another way is to use the Placement New/Delete mechanism on the
previously allocated memory.
Is a complete new area, with a lot of experimenting /testing issues. 

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2010. január 3. 1:00
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

>What is the way to force our allocation functions to be 
>used by QT C++ new/delete operators?

>Without this, any fm.c leak measurement is pointless 
>for QT subsystem, as our fmstat modules is just not used 
>at all by it.

I can see hacks just for the static builds, but it is a hard way, in any
case...



___
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] hbide converts the path to lowercase.

[Bisz István]

Hi,

 

The lowercase conversion:

 

/home/Istvan/Downloads/harbour/contrib/hbide/

 

generates the following error on linux:

 

File not found:

/home/istvan/downloads/harbour/contrib/hbide/hbide.prg

 

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] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

Hi Przemek,

First of all Happy New Year!

The intention behind of this message, is to inform the developer that 
everything goes well: the FM statistic module collects the necessary info and 
the analysis at the end of the program execution detects that there is no 
memory leak. In the previous solution the analyzer remained mute in this 
situation (no memory leak detected) and the developer tried to hunt for a 
possible bug, this was my experience too, maybe it was my fault. So my 
impression is that this info can be useful for the developers, that the all 
allocated blocks are released correctly.

To be exact, this is the final solution implemented here by Viktor with the 
same intention behind as I understood correctly.

Best regards,
István

-Original Message-
From: harbour-boun...@harbour-project.org 
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
Sent: 2010. január 4. 16:06
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

On Mon, 04 Jan 2010, Szak�ts Viktor wrote:

Hi,

> > If this is the only reason then we should revert this modification.
> > For such functionality we have //info switch which can be used to
> > verify if FM statistic module is enabled and how much memory was
> > allocated and released. Just simply run any applications with this
> > switch, i.e.:
> >   myapp.exe //info
> Can you pls do it? I'm unsure what should be the "revert" 
> state here, I did about 3-4 modifications after Istvan's 
> initial one.

I was talking about these lines added by Istvan:

   else
   {
  hb_conOutErr( hb_conNewLine(), 0 );
  hb_snprintf( buffer, sizeof( buffer ), HB_I_("Memory allocated but not 
released: none") );
  hb_conOutErr( buffer, 0 );
   }

When //info runtime switch is used (explicitly as application parameter
or using HARBOUR envvar) then memory statistic is always present so it's
not necessary to show such dummy message.
Before I'll remove it I'll wait for Istvan opinion.

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] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

OK. Maybe I was too happy to see this message, sorry.

-Original Message-
From: harbour-boun...@harbour-project.org 
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
Sent: 2010. január 4. 17:49
To: Harbour Project Main Developer List.
Subject: Re: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

On Mon, 04 Jan 2010, Bisz István wrote:

Hi,

> First of all Happy New Year!

Thank you and Happy New Year.

> The intention behind of this message, is to inform the developer that
> everything goes well: the FM statistic module collects the necessary
> info and the analysis at the end of the program execution detects that
> there is no memory leak. In the previous solution the analyzer remained
> mute in this situation (no memory leak detected) and the developer tried
> to hunt for a possible bug, this was my experience too, maybe it was my
> fault. So my impression is that this info can be useful for the developers,
> that the all allocated blocks are released correctly.
> To be exact, this is the final solution implemented here by Viktor with
> the same intention behind as I understood correctly.

So such functionality existed before and this modification is redundant
and effects output of all programs linked with memory statistic module
All what you need is running your progrm with //info parameter.
Just try.
IMHO it's much better solution then adding the message:
   "Memory allocated but not released: none"
which is always shown when application is closed.

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: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

[Bisz István]

OK. Is more cleaner.

An another issue is I think is in hbtrace.c with the following line:

 MultiByteToWideChar( CP_ACP, 0, hb_strncpy( message, buf.psz, sizeof( 
message ) - 1 ), -1,
  buf.lp, HB_SIZEOFARRAY( buf.lp ) );

The strncpy( message, buf.psz, sizeof( message ) - 1 ) can lead into a 
recursive HB_TRACE call, as it happened in one of my test case.

Best regards,
István

-Original Message-
From: harbour-boun...@harbour-project.org 
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
Sent: 2010. január 4. 18:09
To: Harbour Project Main Developer List.
Subject: Re: RE: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour

On Mon, 04 Jan 2010, Bisz István wrote:
> OK. Maybe I was too happy to see this message, sorry.

Ups. I've just seen that it was not always shown but only
when //INFO were used so it's fine for me. I only suggest
to replace:
   hb_snprintf( buffer, sizeof( buffer ),
HB_I_("Memory allocated but not released: none") );
   hb_conOutErr( buffer, 0 );
with simple:
   hb_conOutErr( HB_I_("Memory allocated but not released: none"), 0 );

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

[Harbour] (no subject)

[Bisz István]

Hi,

 

hbtrace.c

../../../hbtrace.c(250) : error C2664: 'MultiByteToWideChar' : cannot
convert parameter 3 from 'void *' to 'LPCSTR'

Conversion from 'void*' to pointer to non-'void' requires an
explicit cast

win-make[3]: *** [hbtrace.obj] Error 2

win-make[2]: *** [descend] Error 2

win-make[1]: *** [common.inst] Error 2

win-make: *** [src.inst] Error 2

 

Best regards,

István

 

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Qt - hbqt, demoqt, demoxbp and hbide interface test.

[Bisz István]

Hi,

 

After the latest commits, I successfully (crash-free) tested the Qt - hbqt,
demoqt, demoxbp and hbide. The scope of these test cases are just focusing
on the different platforms and development environments, without functional
tests.

The test was executed on Vista SP2 and Fedora 12 with the latest updates
executed.

The good news is that now the MinGW with GCC 4.4.1 Windows builds and MinGW
with GCC 4.4.2 linux cross builds are crash free, the delete operators are
executed smoothly.

 

The following combinations are tested.

1.  Qt 4.5.3 for MinGW
(http://get.qt.nokia.com/qt/source/qt-win-opensource-4.5.3-mingw.exe)

habour,  hbqt, demoqt, demoxbp and hbide built with

http://sunet.dl.sourceforge.net/project/tdm-gcc/TDM-MinGW%20Installer/1.908.
0/tdm-mingw-1.908.0-4.4.1-2.exe with SJLJ rewinding.

2.  Qt 4.6.0 for MinGW
(http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-mingw.exe)

habour,  hbqt, demoqt, demoxbp and hbide built with

http://sunet.dl.sourceforge.net/project/tdm-gcc/TDM-MinGW%20Installer/1.908.
0/tdm-mingw-1.908.0-4.4.1-2.exe with Dwarf-2 rewinding.

3.  Qt 4.6.0 for vs2008
(http://get.qt.nokia.com/qt/source/qt-win-opensource-4.6.0-vs2008.exe)

habour,  hbqt, demoqt, demoxbp and hbide built with VS2008

4.  Qt 4.5.3 Fedora 12 package

habour,  hbqt, demoqt, demoxbp and hbide built with Fedora12 GCC4.4.3

5.  Qt 4.5.3 for MinGW
(http://get.qt.nokia.com/qt/source/qt-win-opensource-4.5.3-mingw.exe)

6.  habour,  hbqt, demoqt, demoxbp and hbide cross-built with Fedora 12
MinGW with GCC 4.4.2

 

Pritpal, could you please change the release method setting at the beginning
of the hbide and demoxbp to:

 

   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DESTRUTOR )  //
Exits cleanly

   HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE )
//  Exits cleanly

   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE_LATER ) //  Exits
cleanly

 

I am requesting in this way, to avoid undesired interferences with the same
prg-s updates. Thank you.

Note: The demoqt already works with this release method activated.

 

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] HBIDE + FMSTAT

[Bisz István]

Hi Viktor,

Please apply:

   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DESTRUTOR )  //
Exits cleanly
   HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE )
//  Exits cleanly
   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE_LATER ) //  Exits
cleanly

The remaining should be analyzed.

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: 2010. január 5. 19:26
To: Harbour Project Main Developer List.
Subject: [Harbour] HBIDE + FMSTAT

Hi All,

I got this result with FMSTAT enabled in VM, and 
running HBIDE (starting and exiting with no file open), 
using MinGW 4.4.1-2 and QT 4.5.3.

---
Application Memory Allocation Report -
F:\work\harbour\harbour\contrib\hbide\hbide.exe
Terminated at: 2010.01.05 19:23:54
Total memory allocated: 2000693 bytes (26914 block(s))
Warning, memory allocated but not released: 4340 bytes (243 block(s))
Block 1 0x347190 (size 8) hb_stackInit(0), "88BB3A6A"
Block 2 0x9df100 (size 8) QT_QFILE(0), "88BB3A6A"
Block 3 0xa08fe0 (size 12) QT_QUILOADER(0), "88BB3A6A1883A000"
Block 4 0x9de390 (size 4) QT_QUILOADER(0), "88F89A00"
Block 5 0x9de128 (size 8) QT_QUILOADER_LOAD(0), "0600C8952D02"
Block 6 0x9d2050 (size 8) QT_QUILOADER_LOAD(0), "070068D12D02"
Block 7 0x9cf948 (size 8) QT_QUILOADER_LOAD(0), "0800480E2D02"
Block 8 0x9caaf8 (size 8) QT_QUILOADER_LOAD(0), "0900780E2D02"
Block 9 0x9c6b58 (size 8) QT_QUILOADER_LOAD(0), "0A00D80E2D02"
Block 10 0xa0bab8 (size 12) QT_QUILOADER_LOAD(0), "02001B0048FC9A00"
Block 11 0xa0bb28 (size 12) QT_QUILOADER_LOAD(0), "03001D00080C2D02"
Block 12 0xa0bb98 (size 12) QT_QUILOADER_LOAD(0), "04001E00080F2D02"
Block 13 0xa0bc08 (size 12) QT_QUILOADER_LOAD(0), "05001F00380C2D02"
Block 14 0xa0bc78 (size 20) QT_QUILOADER_LOAD(0),
"E88C8765D0C02D02D48D87653C0088C12D02"
Block 15 0xa0bcf0 (size 12) QT_QUILOADER_LOAD(0), "E82C840010132D02F0F99A00"
Block 16 0xa0bd60 (size 20) QT_QUILOADER_LOAD(0),
"2880886540932D02108188653900F8932D02"
Block 17 0xa0bdd8 (size 20) QT_QUILOADER_LOAD(0),
"88BB3A6AE8A88765390008092F02"
Block 18 0xa0be50 (size 20) QT_QUILOADER_LOAD(0),
"88BB3A6AE8A887653A0020482F02"
Block 19 0x2400090 (size 12) QT_SLOTS_NEW(0), "88BB3A6A74F0336A"
Block 20 0x24056a0 (size 20) QT_EVENTS_NEW(0),
"88BB3A6A74F0336A74F0336AD0712D02"
Block 21 0x23fddc8 (size 8) QT_QEVENTLOOP(0), "88BB3A6A"
Block 22 0x24f7fd8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 23 0x2453858 (size 8) QT_QACTION(0), "88BB3A6A"
Block 24 0xa06310 (size 8) QT_QACTION(0), "88BB3A6A"
Block 25 0xa05510 (size 8) QT_QACTION(0), "88BB3A6A"
Block 26 0x342668 (size 8) QT_QACTION(0), "88BB3A6A"
Block 27 0x3417a0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 28 0x340160 (size 8) QT_QACTION(0), "88BB3A6A"
Block 29 0x2457880 (size 8) QT_QACTION(0), "88BB3A6A"
Block 30 0x2459aa0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 31 0x245a7a8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 32 0x245a990 (size 8) QT_QACTION(0), "88BB3A6A"
Block 33 0x245ab78 (size 8) QT_QACTION(0), "88BB3A6A"
Block 34 0x245ad60 (size 8) QT_QACTION(0), "88BB3A6A"
Block 35 0x245af48 (size 8) QT_QACTION(0), "88BB3A6A"
Block 36 0x245c680 (size 8) QT_QACTION(0), "88BB3A6A"
Block 37 0x245c7f0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 38 0x245c9d8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 39 0x245cbc0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 40 0x245cda8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 41 0x245a090 (size 8) QT_QACTION(0), "88BB3A6A"
Block 42 0x245cf90 (size 8) QT_QACTION(0), "88BB3A6A"
Block 43 0x245cff8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 44 0x245a278 (size 8) QT_QACTION(0), "88BB3A6A"
Block 45 0x24f8ba0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 46 0x24f8d88 (size 8) QT_QACTION(0), "88BB3A6A"
Block 47 0x24f8f70 (size 8) QT_QACTION(0), "88BB3A6A"
Block 48 0x24f9158 (size 8) QT_QACTION(0), "88BB3A6A"
Block 49 0x24f9340 (size 8) QT_QACTION(0), "88BB3A6A"
Block 50 0x24f9528 (size 8) QT_QACTION(0), "88BB3A6A"
Block 51 0x24f9710 (size 8) QT_QACTION(0), "88BB3A6A"
Block 52 0x24f98f8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 53 0x24f9ae0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 54 0x24f9cc8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 55 0x24fa810 (size 8) QT_QACTION(0), "88BB3A6A"
Block 56 0x24fa9f8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 57 0x24fabe0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 58 0x24fadc8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 59 0x9fe4e8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 60 0x24fae30 (size 8) QT_QACTION(0), "88BB3A6A"
Block 61 0x24faea0 (size 8) QT_QACTION(0), "

RE: [Harbour] HBIDE + FMSTAT

[Bisz István]

Hi Viktor,

First impression is, GREAT AND NICE! A new tool in our hands. I am
rebuilding now, so this is just a brief info. Thank you.

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: 2010. január 5. 19:42
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] HBIDE + FMSTAT

Hi Istvan,

>   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DESTRUTOR )  //
> Exits cleanly
>   HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE )
> //  Exits cleanly
>   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE_LATER ) //
Exits
> cleanly
> 
> The remaining should be analyzed.

Results with above patch: (+ crash at exit)
---
Application Memory Allocation Report -
F:\work\harbour\harbour\contrib\hbide\hbide.exe
Terminated at: 2010.01.05 19:40:18
Total memory allocated: 2000661 bytes (26912 block(s))
Warning, memory allocated but not released: 4268 bytes (239 block(s))
Block 1 0x352668 (size 8) hb_stackInit(0), "88BB3A6A"
Block 2 0xa0f188 (size 8) QT_QFILE(0), "88BB3A6A"
Block 3 0x9ce390 (size 4) QT_QUILOADER(0), "88F89D00"
Block 4 0x9ce128 (size 8) QT_QUILOADER_LOAD(0), "0600C8953902"
Block 5 0x9c2050 (size 8) QT_QUILOADER_LOAD(0), "070068D13902"
Block 6 0x9bf948 (size 8) QT_QUILOADER_LOAD(0), "0800480E3902"
Block 7 0x9baaf8 (size 8) QT_QUILOADER_LOAD(0), "0900780E3902"
Block 8 0x9b6b58 (size 8) QT_QUILOADER_LOAD(0), "0A00D80E3902"
Block 9 0xa1ab60 (size 12) QT_QUILOADER_LOAD(0), "02001B0048FC9D00"
Block 10 0xa1abd0 (size 12) QT_QUILOADER_LOAD(0), "03001D00080C3902"
Block 11 0xa1ac40 (size 12) QT_QUILOADER_LOAD(0), "04001E00080F3902"
Block 12 0xa1acb0 (size 12) QT_QUILOADER_LOAD(0), "05001F00380C3902"
Block 13 0xa1ad20 (size 20) QT_QUILOADER_LOAD(0),
"E88C8765D0C03902D48D8765380088C13902"
Block 14 0xa1ad98 (size 12) QT_QUILOADER_LOAD(0), "E82C840010133902F0F99D00"
Block 15 0xa1ae08 (size 20) QT_QUILOADER_LOAD(0),
"2880886540933902108188653D00F8933902"
Block 16 0xa1ae80 (size 20) QT_QUILOADER_LOAD(0),
"88BB3A6AE8A887653C0008093B02"
Block 17 0xa1aef8 (size 20) QT_QUILOADER_LOAD(0),
"88BB3A6AE8A887653B0020483B02"
Block 18 0xa7d350 (size 8) QT_QEVENTLOOP(0), "88BB3A6A"
Block 19 0xcd8138 (size 8) QT_QACTION(0), "88BB3A6A"
Block 20 0xcd69d0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 21 0xcbd428 (size 8) QT_QACTION(0), "88BB3A6A"
Block 22 0x9fc3c0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 23 0x9ecd08 (size 8) QT_QACTION(0), "88BB3A6A"
Block 24 0x9e6cb0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 25 0x9ead00 (size 8) QT_QACTION(0), "88BB3A6A"
Block 26 0xcd0610 (size 8) QT_QACTION(0), "88BB3A6A"
Block 27 0xcd31d8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 28 0xcd34b0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 29 0xcd3698 (size 8) QT_QACTION(0), "88BB3A6A"
Block 30 0xcd3880 (size 8) QT_QACTION(0), "88BB3A6A"
Block 31 0xcd3a68 (size 8) QT_QACTION(0), "88BB3A6A"
Block 32 0xcd3c50 (size 8) QT_QACTION(0), "88BB3A6A"
Block 33 0xcd5388 (size 8) QT_QACTION(0), "88BB3A6A"
Block 34 0xcd54f8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 35 0xcd56e0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 36 0xcd58c8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 37 0xcd5ab0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 38 0xcd2368 (size 8) QT_QACTION(0), "88BB3A6A"
Block 39 0xcd5c98 (size 8) QT_QACTION(0), "88BB3A6A"
Block 40 0xcd5d00 (size 8) QT_QACTION(0), "88BB3A6A"
Block 41 0xcd2550 (size 8) QT_QACTION(0), "88BB3A6A"
Block 42 0xcd8c80 (size 8) QT_QACTION(0), "88BB3A6A"
Block 43 0xcd8e68 (size 8) QT_QACTION(0), "88BB3A6A"
Block 44 0xcd9050 (size 8) QT_QACTION(0), "88BB3A6A"
Block 45 0xcd9238 (size 8) QT_QACTION(0), "88BB3A6A"
Block 46 0xcd9420 (size 8) QT_QACTION(0), "88BB3A6A"
Block 47 0xcd9608 (size 8) QT_QACTION(0), "88BB3A6A"
Block 48 0xcd97f0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 49 0xcd99d8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 50 0xcd9bc0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 51 0xcd9da8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 52 0xcda8f0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 53 0xcdaad8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 54 0xcdacc0 (size 8) QT_QACTION(0), "88BB3A6A"
Block 55 0xcdaea8 (size 8) QT_QACTION(0), "88BB3A6A"
Block 56 0xcb6910 (size 8) QT_QACTION(0), "88BB3A6A"
Block 57 0xcdaf10 (size 8) QT_QACTION(0), "88BB3A6A"
Block 58 0xcdaf80 (size 8) QT_QACTION(0), "88BB3A6A"
Block 59 0xcdb660 (size 8) QT_QACTION(0), "88BB3A6A"
Block 60 0xcdb848 (size 8) QT_QACTION(0), "88BB3A6A"
Block 61 0xcdba30 (size 8) QT_QACTION(0), "88BB3A6A"
Block 62 0xcdbc18 (size 8) QT_QACTION(0

RE: [Harbour] HBIDE + FMSTAT

[Bisz István]

Hi Viktor,

My experiences are different here (hbide) just 32 blocks with VS2008 build
and maybe the same crash at the end:

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 1 (size 4)
../../../hbstr.c(800), "6083DB01"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 2 (size 8)
../../../hbstr.c(800), "060058F0E801"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 3 (size 8)
../../../hbstr.c(800), "0700F067E801"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 4 (size 8)
../../../hbstr.c(800), "0800287AE701"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 5 (size 8)
../../../hbstr.c(800), "0900587AE701"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 6 (size 8)
../../../hbstr.c(800), "0A00B87AE701"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 7 (size 12)
../../../hbstr.c(800), "02001B00B8EFE801"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 8 (size 12)
../../../hbstr.c(800), "03001D00E877E701"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 9 (size 12)
../../../hbstr.c(800), "04001E00E87AE701"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 10 (size 12)
../../../hbstr.c(800), "05001F001878E701"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 11 (size 20)
../../../hbstr.c(800), "6C8C7900107FE7014C8C79003FFFC87FE701"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 12 (size 12)
../../../hbstr.c(800), "381B7A00D03FE70100EEE801"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 13 (size 20)
../../../hbstr.c(800), "8C0C79007847E801700C79003048E801"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 14 (size 20)
../../../hbstr.c(800), "E4E3780020F61904C8E37800D8F61904"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 15 (size 12)
../../../hbstr.c(800), "381B7A00383E1904707B1804"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 16 (size 20)
../../../hbstr.c(800), "E474790090F71904C474790048F81904"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 17 (size 20)
../../../hbstr.c(800), "E47479F91904C4747900B8F91904"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 18 (size 20)
../../../hbstr.c(800), "E474790020D2EF01C4747900D8D2EF01"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 19 (size 20)
../../../hbstr.c(800), "B4E5790080FE190498E5790038FF1904"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 20 (size 20)
../../../hbstr.c(800), "CCEA79001898F401B0EA7900D098F401"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 21 (size 20)
../../../hbstr.c(800), "CCEA7900D0121B04B0EA790088131B04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 22 (size 20)
../../../hbstr.c(800), "949A79008099F401749A7900389AF401"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 23 (size 20)
../../../hbstr.c(800), "A4A7790008131A0488A77900C0131A04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 24 (size 20)
../../../hbstr.c(800), "FC70790038141B04DC707900F0141B04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 25 (size 20)
../../../hbstr.c(800), "FC707900A0151B04DC70790058161B04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 26 (size 20)
../../../hbstr.c(800), "A4A7790048141A0488A779151A04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 27 (size 20)
../../../hbstr.c(800), "FC70790008171B04DC707900C0171B04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 28 (size 20)
../../../hbstr.c(800), "FC70790070181B04DC70790028191B04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 29 (size 20)
../../../hbstr.c(800), "CCEA7900D8191B04B0EA7900901A1B04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 30 (size 20)
../../../hbstr.c(800), "CCEA7900401B1B04B0EA7900F81B1B04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 31 (size 20)
../../../hbstr.c(800), "B4E5790088151A0498E5790040161A04"
c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 32 (size 20)
../../../hbstr.c(800), "949A7900581B1A04749A7900101C1A04"

The block structure printout is different, are we running different tools?

Best regards,
István

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2010. január 5. 19:52
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] HBIDE + FMSTAT

Hi Viktor,

First impression is, GREAT AND NICE! A new tool in our hands. I am
rebuildin

RE: [Harbour] demoqt hb_xgrab requested to allocate zero bytes

[Bisz István]

Hi Lorenzo,

> Am I missing sth?

Fedora 12 
---
Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes
Called from QT_QEVENTLOOP_PROCESSEVENTS(0)
Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg
Called from APPEVENT(0) in ../../../xbpgeneric.prg
Called from HBIDE:CREATE(345) in hbide.prg
Called from MAIN(104) in hbide.prg

Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes
Called from QT_QFONTMETRICS_WIDTH(0)
Called from QFONTMETRICS:WIDTH(0) in ../../../TQFontMetrics.prg
Called from XBPBROWSE:DOCONFIGURE(0) in ../../../xbpbrowse.prg
Called from XBPBROWSE:ADDCOLUMN(0) in ../../../xbpbrowse.prg
Called from BUILD_BROWSE(1743) in demoxbp.prg
Called from BUILDADIALOG(177) in demoxbp.prg
Called from _BUILDADIALOG(111) in demoxbp.prg
Called from MAIN(102) in demoxbp.prg

Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes
Called from QT_QLINEEDIT_SETTEXT(0)
Called from QLINEEDIT:SETTEXT(0) in ../../../TQLineEdit.prg
Called from BUILD_CONTROLS(544) in demoqt.prg
Called from BUILD_TABS(467) in demoqt.prg
Called from MAIN(169) in demoqt.prg
---

Solved with:
 
hbmk2 -nohbcppmm demoqt ...
hbmk2 -nohbcppmm demoxbp ...

for hbide the -nohbcppmm switch is unfortunately ineffective here, the
hbcppmm is generated and linked to hbide.

Best regards,
István


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Fedora 12 build error

[Bisz István]

Hi,

 

../../../hbznet.c:63:19: error: zutil.h: No such file or directory

../../../hbznet.c: In function ‘_HB_ZNETSTREAM* hb_znetOpen(int, int)’:

../../../hbznet.c:107: error: ‘DEF_MEM_LEVEL’ was not declared in this scope

make[3]: *** [hbznet.o] Error 1

make[2]: *** [descend] Error 2

make[1]: *** [rtl.inst] Error 2

make: *** [src.inst] Error 2

 

Solved with: export HB_WITH_ZLIB=local

 

Best regards,

István

  

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 VS2008 test

[Bisz István]

Hi,

 

The hbide crashes at the very end. The demoqt and demoxbp runs smoothly.

 

See blow the traces generated:

 

1.  demoqt

 

Harbour Terminal: Windows dummy console for GUI programs

Harbour 2.0.1dev (Rev. 13487)

Windows Vista 6.0.6002 Service Pack 2

DS avail=1948668KB  OS avail=2015804KB  EMM avail=0KB  MemStat:On  MT:Off

 



Total memory allocated: 742510 bytes (8781 block(s))

Memory allocated but not released: none

 

2.  demoxbp

 

Harbour Terminal: NULL

Harbour 2.0.1dev (Rev. 13487)

Windows Vista 6.0.6002 Service Pack 2

DS avail=1949684KB  OS avail=2031240KB  EMM avail=0KB  MemStat:On  MT:Off

 



Total memory allocated: 2628636 bytes (29358 block(s))

Memory allocated but not released: none

 

3.  hbide

 

Harbour Terminal: NULL

Harbour 2.0.1dev (Rev. 13487)

Windows Vista 6.0.6002 Service Pack 2

DS avail=1934264KB  OS avail=2028260KB  EMM avail=0KB  MemStat:On  MT:Off

idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS
==

idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS Before::oDlg:destroy()
1975303  34180

idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS


idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS


idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS After ::oDlg:destroy()
1760361  34180

idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS
==

idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS EXITING after destroy 
1759381  34180

 



Total memory allocated: 1977633 bytes (26502 block(s))

Warning, memory allocated but not released: 644 bytes (32 block(s))

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 1 (size 4)
QT_QUILOADER(0), "70833B00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 2 (size 8)
QT_QUILOADER_LOAD(0), "06A48D00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 3 (size 8)
QT_QUILOADER_LOAD(0), "0700E0A53B00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 4 (size 8)
QT_QUILOADER_LOAD(0), "08EF8C00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 5 (size 8)
QT_QUILOADER_LOAD(0), "090030EF8C00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 6 (size 8)
QT_QUILOADER_LOAD(0), "0A00B0298E00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 7 (size 12)
QT_QUILOADER_LOAD(0), "02001B0060A38D00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 8 (size 12)
QT_QUILOADER_LOAD(0), "03001D00C0EC8C00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 9 (size 12)
QT_QUILOADER_LOAD(0), "04001E00E0298E00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 10 (size 12)
QT_QUILOADER_LOAD(0), "05001F00F0EC8C00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 11 (size 20)
QT_QUILOADER_LOAD(0), "FC427900487E8C00DC42797F8C00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 12 (size 12)
QT_QUILOADER_LOAD(0), "C8D17900F8258C00A8A18D00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 13 (size 20)
QT_QUILOADER_LOAD(0), "1CC37800809D8DC37800389E8D00"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 14 (size 20)
QT_QUILOADER_LOAD(0), "749A7800401A1004589A7800F81A1004"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 15 (size 12)
QT_QUILOADER_LOAD(0), "C8D1790020470E04409C0E04"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 16 (size 20)
QT_QUILOADER_LOAD(0), "742B7900B01B1004542B79008100681C1004"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 17 (size 20)
QT_QUILOADER_LOAD(0), "742B7900201D1004542B7900D81D1004"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 18 (size 20)
QT_QUILOADER_LOAD(0), "742B7900781A9500542B7900301B9500"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 19 (size 20)
QT_QUILOADER_LOAD(0), "449C7900A0421004289C79008CFF58431004"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 20 (size 20)
QT_QUILOADER_LOAD(0), "5CA17900304B110440A179008100E84B1104"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 21 (size 20)
QT_QUILOADER_LOAD(0), "5CA17900B04C110440A17900684D1104"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 22 (size 20)
QT_QUILOADER_LOAD(0), "24517900986C110404517900506D1104"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 23 (size 20)
QT_QUILOADER_LOAD(0), "345E790088451004185E79007DFF40461004"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 24 (size 20)
QT_QUILOADER_LOAD(0), "8C277900184E11046C2779008100D04E1104"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 25 (size 20)
QT_QUILOADER_LOAD(0), "8C277900804F11046C27790038501104"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 26 (size 20)
QT_QUILOADER_LOAD(0), "345E7900486E1104185E796F1104"

c:\d

RE: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

[Bisz István]

> Please just be creative, and simply remove -hbcppmm from hbqt.hbc locally
to disable this option. I'll look into it later.
OK. Thanks.

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] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

[Bisz István]

Hi,

Maybe the following thread:
 
http://lists.trolltech.com/qt-interest/2000-09/thread3-0.html

contains the answer for your chew over this issue.

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: 2010. január 6. 19:01
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

So maybe the problem is that our malloc/realloc doesn't 
handle zero size, while std version do.

In this case, we should probably allow zero size too.

Brgds,
Viktor

On 2010 Jan 6, at 18:46, Bisz István wrote:

> Hi,
> 
> Finally, I was able to put in work the hbcppmm on Fedora12 by inserting the
> "'   if ( nSize == 0 ) nSize = 1;'
>  + Chr( 10 ) +;"
> line in hbmk2.prg for both new operators generator sequences. As I understood 
> correctly this is the "hack" of GCC to handle zero sized object allocation. 
> If not, correct me.
> 
> Please fin attached the trace files generated on Fedora12 for fully 
> functional demoqt, demoxbp and hbide.
> 
> Best regards,
> István
> 
> ___
> 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] C (++) question

[Bisz István]

Hi Przemek,

 

I am coming initially from an 8BIT world, my main task was until your
mailing list is to write things on a predefined processor in a completely
different world no linux no windows etc.

I am engaged on this list to implement a test software to my devices
historically started with clipper, I don’t know the original version, so is
a long history, unimportant.

 

It is not related to this list, but personally I am interesting your opinion
about this issue. If you haven’t enough time ignore it.

 

In may analyzis of the assemble code of the: 

if ( nSize == 0 ) nSize = 1;,

was more efficient that:

if ( !size ) size++;

at least with Keil C compiler for Dallas DS80C320, how do you think? Thank
you in advance.

 

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] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

[Bisz István]

Hi Viktor,

For me is OK thank you, but we always should think about a general user.

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: 2010. január 6. 22:27
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1
test

Hi Istvan,

> The hbmk2 –nohbcppmm is ineffective for hbide, so now we can’t test hbide
on linux, maybe it is specific just to Fedora12.

To disable hbcppmm for hbide, pls try this command line:
  hbmk2 hbide.hbp -nohbcppmm

The order of options is significant. If you issue -nohbcppmm 
first, it will be overridden (by hbide.hbp -> hbxbp.hbc -> hbqt.hbc ->
hbcppmm=yes).

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: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

[Bisz István]

Hi Viktor,

We should made changes in a way that a "general user isn't affected" if it
is possible. This is a general rule in every system life cycle.
No problem we can handle it, as we are in development phase, forget it.

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] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

[Bisz István]

Dear Viktor,

You are right, the first goal is the software quality, but don't forget that
there are peoples without so much knowledge about the inner things. Maybe
sometimes should be useful to put yourself in their position. But please
consider these words, without any negative intentions, as an advice from a
people coming from harbour external world.

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] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

[Bisz István]

As I see, maybe undesirable, as this list is declared a developers' list,
but there are a lot of users in this list requesting knowledge from (us). 
I don't know, but we are compulsively to serve them, but now we are far away
from our starting point. We should generate less protuberance in the system
under development, if it is possible. It was just light observation leading
in this discussion now, sorry, it's time to finish it.

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] C (++) question

[Bisz István]

Hi,

Thank you for the clarification.

Best regards,
István

-Original Message-
From: harbour-boun...@harbour-project.org 
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
Sent: 2010. január 7. 7:42
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] C (++) question

On Wed, 06 Jan 2010, Bisz István wrote:

Hi,

> In may analyzis of the assemble code of the: 
> if ( nSize == 0 ) nSize = 1;,
> was more efficient that:
> if ( !size ) size++;
> at least with Keil C compiler for Dallas DS80C320, how do you think? Thank
> you in advance.

Yes in most of CPUs it's faster (but not all, i.e some CPUs have instruction
to INC/DEC memory cell but have no instruction to assing direct value so
such operation has to be done indirectly by register) and of course
   if( !size ) size = 1;
is cleaner. I should not write the previous version and confuse user.
Anyhow modern C compilers can fully optimize such C code and generate
the same optimal code for both versions, i.e. try this:
   /* tst.c */
   static int size = 0;
   void f1( void ) { if( !size ) size = 1; }
   void f2( void ) { if( !size ) size++; }
   void f3( void ) { if( !size ) ++size; }
with
   gcc -O3 tst.c -S
and you will find that for f1(), f2() and f3() the same code
is generated. The difference is only with older compilers which
do not make advanced optimizations.
Sorry for confusion but each of us has some habits and I also was
using 8 computers in the past and sometime I use some constructions
which were better optimized but in this case I probably wanted to
safe one character in example ;-) I do not even remember because
it was unimportant for me and I know that it does not make any
difference for advanced optimizations in modern C compilers.

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] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test

[Bisz István]

Hi,

> In Fedora12 you can use valgrind which should give much
> precise results.

Thank you for the details. The link below contains the valgrind log files for 
demoqt, demoxbp and hbide and a suppressions file: qt.supp:
{
demoqt_suppress_QApplication
Memcheck:Leak
...
fun:_ZN12QApplicationC1ERiPPci
...
}

The suppression file is necessary to suppress the errors of the not released 
resources generated by the QApplication constructor at the program 
initialization.
The Qt designers decided that the resources allocated by QApplication 
constructor are not released by the delete operator execution. This resources 
are released together with the program termination. 

http://www.easy-share.com/1908937902/valgrind.qt.fedora12.zip

Best regards,
István


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Fedora 12 build status

[Bisz István]

Hi,

 

We have now:

 

1.  Fedora 12 native build:

 

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrFromRaw(HB_FATTR)’:

../../../hbffind.c:179: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrToRaw(HB_FATTR)’:

../../../hbffind.c:261: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘char* hb_fsAttrDecode(HB_FATTR, char*)’:

../../../hbffind.c:365: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrFromRaw(HB_FATTR)’:

../../../hbffind.c:179: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrToRaw(HB_FATTR)’:

../../../hbffind.c:261: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘char* hb_fsAttrDecode(HB_FATTR, char*)’:

../../../hbffind.c:365: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

In file included from ../../../hvmall.c:94:

../../../set.c: In function ‘HB_BOOL is_devicename(const char*)’:

../../../set.c:223: error: invalid conversion from ‘ULONG*’ to ‘HB_FATTR*’

../../../set.c:223: error:   initializing argument 2 of ‘HB_BOOL
hb_fsGetAttr(const char*, HB_FATTR*)’

make[3]: *** [hvmall.o] Error 1

make[2]: *** [descend] Error 2

make[1]: *** [vm.inst] Error 2

make: *** [src.inst] Error 2

 

2.  Fedora 12 Windows cross build:

 

../../../dates2.c:105: warning: 'int hb_wom(int, int, int)' defined but not
used

../../../hbsqlit3.c:233: warning: 'HB_BOOL hb_sqlite3_store(void*, int,
int)' defined but not used

 

Best regards,

István

 

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] (no subject)

[Bisz István]

Hi Pritpal,

 

Could you please definitively switch in your development environment the
release method  to HBQT_RELEASE_WITH_DELETE:

 

   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DESTRUTOR ) //
Exits cleanly
   HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE )  //
Exits cleanly
   //HBQT_SET_RELEASE_METHOD( HBQT_RELEASE_WITH_DELETE_LATER )  //
Exits cleanly



In QUiLoader.cpp I changed temporarily the QT_QUILOADER_LOAD to: 

 

/*
 * QWidget * load ( QIODevice * device, QWidget * parentWidget = 0 )
 */
HB_FUNC( QT_QUILOADER_LOAD )
{
//   hb_retptr( ( QWidget* ) hbqt_par_QUiLoader( 1 )->load(
hbqt_par_QIODevice( 2 ), hbqt_par_QWidget( 3 ) ) );
   hb_retptrGC( hbqt_gcAllocate_QWidget( ( QWidget* ) hbqt_par_QUiLoader( 1
)->load( hbqt_par_QIODevice( 2 ), hbqt_par_QWidget( 3 ) ) ) );
}

reducing the FM statistic to:

 



Total memory allocated: 2383683 bytes (31688 block(s))

Warning, memory allocated but not released: 132 bytes (10 block(s))

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 1 (size 4)
QT_QUILOADER(0), "7083FB01"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 2 (size 8)
QT_QUILOADER_LOAD(0), "06A4CF01"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 3 (size 8)
QT_QUILOADER_LOAD(0), "0700E0A5FB01"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 4 (size 8)
QT_QUILOADER_LOAD(0), "08EFCE01"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 5 (size 8)
QT_QUILOADER_LOAD(0), "090030EFCE01"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 6 (size 8)
QT_QUILOADER_LOAD(0), "0A00B029D001"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 7 (size 12)
QT_QUILOADER_LOAD(0), "02001B0060A3CF01"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 8 (size 12)
QT_QUILOADER_LOAD(0), "03001D00C0ECCE01"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 9 (size 12)
QT_QUILOADER_LOAD(0), "04001E00E029D001"

c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 10 (size 12)
QT_QUILOADER_LOAD(0), "05001F00F0ECCE01" 

 

Maybe we should have here a general solution for the wrappers returning
objects, some of them are already solved with inserting their pointers to
the GC system evidence.

 

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] (no subject)

[Bisz István]

Hi,

> In hbIDE or in hbQT as a whole ?
> In hbIDE I have changed it as default.

The hbIDE downloaded from SVN the HBQT_RELEASE_WITH_DESTRUTOR is selected. 

Generally we should use HBQT_RELEASE_WITH_DELETE.

> Are you done with your experiments with HBQT_RELEASE_WITH_* and 
> have come to conclusion that HBQT_RELEASE_WITH_DELETE is the best ?
> OR
> We need more time to decide?

The HBQT_RELEASE_WITH_DESTRUTOR method does not release the memory allocated by 
the operator new.
The HBQT_RELEASE_WITH_DELETE_LATER method releases the allocated memory with a 
delay.

> Done. 
> Will committ today.
 
Thank you. 
 
> A good idea but I am at a loss how we can achieve it dynamically
> and in the generator. The above change you asked is manually added in 
> QUiLoader.qth.

The resources of the objects returned by the wrappers as return value are not 
released automatically by the GC system.
We need here a general solution.

Best regards,
István



___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Fedora12: hbide build error.

[Bisz István]

Hi,

 

ideobject.prg(170) Error E0019  #error 'Method  not declared or declaration mismatch in class '

ideobject.prg(182) Error E0019  #error 'Method  not declared or declaration mismatch in class '

hbmk2: Error: Running Harbour compiler (embedded). 1

(/usr/local/bin/harbour) -n2 hbide.prg ideobject.prg idestylesheets.prg
idetags.prg idemisc.prg ideactions.prg ideeditor.prg idefindreplace.prg
idedocks.prg idesaveload.prg iderequests.prg idethemes.prg
ideprojmanager.prg idesources.prg -DHB_TR_LEVEL_DEBUG -w3 -es2 -gc3
-o.hbmk/linux/gcc/ -i/usr/local/include/harbour -i../hbxbp -i../hbqt

 

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] Fedora12: hbide build error.

[Bisz István]

Hi,

> Must be fixed after r13600.

Thank you, Pritpal.
Both native and Windows cross builds are warning and error free.

Best regards,
István


___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Fedora 12 build

[Bisz István]

Hi,

 

1.  The native harbour build is error free, but still we have some
warnings:

 

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrFromRaw(HB_FATTR)’:

../../../hbffind.c:179: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrToRaw(HB_FATTR)’:

../../../hbffind.c:261: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘char* hb_fsAttrDecode(HB_FATTR, char*)’:

../../../hbffind.c:365: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrFromRaw(HB_FATTR)’:

../../../hbffind.c:179: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘HB_FATTR hb_fsAttrToRaw(HB_FATTR)’:

../../../hbffind.c:261: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../hbffind.c: In function ‘char* hb_fsAttrDecode(HB_FATTR, char*)’:

../../../hbffind.c:365: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 2 has type ‘HB_FATTR’

../../../filesys.c: In function ‘void convert_open_flags(HB_BOOL, HB_FATTR,
USHORT, int*, unsigned int*, int*, int*)’:

../../../filesys.c:397: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../filesys.c: In function ‘HB_FHANDLE hb_fsCreate(const char*,
HB_FATTR)’:

../../../filesys.c:717: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../filesys.c: In function ‘HB_FHANDLE hb_fsCreateEx(const char*,
HB_FATTR, USHORT)’:

../../../filesys.c:779: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../filesys.c: In function ‘HB_BOOL hb_fsSetAttr(const char*,
HB_FATTR)’:

../../../filesys.c:1290: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../filesys.c: In function ‘void convert_open_flags(HB_BOOL, HB_FATTR,
USHORT, int*, unsigned int*, int*, int*)’:

../../../filesys.c:397: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../filesys.c: In function ‘HB_FHANDLE hb_fsCreate(const char*,
HB_FATTR)’:

../../../filesys.c:717: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../filesys.c: In function ‘HB_FHANDLE hb_fsCreateEx(const char*,
HB_FATTR, USHORT)’:

../../../filesys.c:779: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../filesys.c: In function ‘HB_BOOL hb_fsSetAttr(const char*,
HB_FATTR)’:

../../../filesys.c:1290: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../spfiles.c: In function ‘HB_FHANDLE hb_spCreate(const char*,
HB_FATTR)’:

../../../spfiles.c:201: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../spfiles.c: In function ‘HB_FHANDLE hb_spCreateEx(const char*,
HB_FATTR, USHORT)’:

../../../spfiles.c:218: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../spfiles.c: In function ‘HB_FHANDLE hb_spCreate(const char*,
HB_FATTR)’:

../../../spfiles.c:201: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’

../../../spfiles.c: In function ‘HB_FHANDLE hb_spCreateEx(const char*,
HB_FATTR, USHORT)’:

../../../spfiles.c:218: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘HB_FATTR’ 

 

2.  The Windows cross harbour build is error and warning free

 

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] (no subject)

[Bisz István]

Hi,

>> 
>> The HBQT_RELEASE_WITH_DESTRUTOR method does not release the memory
>> allocated by the operator new.
>>

> But logs suggest that it does. Do it tells a lie ?

I think, you are referring to the log generated by the following lines:

HB_TRACE( HB_TR_DEBUG, ( "hbqt_gcRelease_QUiLoader   Object 
deleted! %i B %i KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );

Yes, indeed the message is too optimistic, but in any case shows that the hbqt 
sends a request the Qt layer to do it.
The FM statistic and valgrind output should be the basis of our investigations.

>> The HBQT_RELEASE_WITH_DELETE_LATER method releases the allocated memory
>> with a delay.
>>

> So it should be out of our experiments then. I will remove from generator.

In this way, we will restrict the possibilities of the hbqt based application 
developers.
This release method is useful in a situation when the object is no more 
necessary, but there are some pending events related to this object.

> For sure we need a general solution.
> But the solution above is destructive,  I cannot even compile qtcore
> after changes above to honour 

>   hb_retptrGC( hbqt_gcAllocate_Q*( new Q*( hbqt_par_Q*( 1 )->somefunction( 
> hbqt_par_someparam( 2 ), someparamnext( 3 ) ) ) ) );

> The reason is we never want a "new" object for return values it it is 
> of type FAR. hbQT will not work at all as we will be dealing with local 
> copy of the object in question. If the type is not FAR we can employ
> this technique. This is what is employed currently.

> The solution could be like ( and I did it initially ):

> Construct a GC pointer which holds this pointer and releases the wrapper
> returned pointer.

> BTW I am not a C guru so I may be wrong.

So, this issue should be marked as TODO.

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] (no subject)

[Bisz István]

> BTW, here latest HBIDE shows no more leaks, but it still crashes on exit
(MINGW/WIN7).

Could you please share with us your experiments mainly MINGW/WIN7 and
VS2008/WIN7 (or VS20xx/WIN7) with and without hbcppmm. Thank you in advance.

> HBQT_RELEASE_WITH_DELETE should be made the default on HBQT level, and any
app-level tweaking (in HBIDE, demos) deleted.

I agree, this is now the best direction.

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] (no subject)

[Bisz István]

Hi Viktor,

> MINGW 4.4.1-2 TDM on WIN7/64 crashes at the end, but no hb_out.log is
generated, SVN is r13605. Without hbcppmm, it just exists without error.
Thank you.

MINGW 4.4.1-2 TDM on Vista SP2/32 shows the same behavior.
VS2008 on Vista SP2/32 with hbcppmm crashes at the end but after FM statics
generation. Without hbcppmm, it just exists without error. 

Fedora 12 native build is error free with and without hbcppmm.

Any input from other platforms is useful.

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

[Bisz István]

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

[Bisz István]

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

[Bisz István]

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] To Istvan

[Bisz István]

Hi Francesco,

> My proposal is to change hb_parptrGC with the proper function call
> hbqt_par_QLayout/hbqt_par_QLayoutItem so to apply, in the future,
> hierarchy checks...

> and
> hbqt_par_QLayout( 1 )->addItem( hbqt_par_QLayoutItem( 2 ) )
> to
>(q)->addItem( p )

Yes, my code snippet is just a wrapped one to demonstrate the problem. My
goal is to show the problem not to solve it. I will check time to time this
list sporadic as I am busy with other issues, but in any case I am happy to
see the immense effort of Pritpal and others to make harbour graphical
solution more attractive and robust. 

Thank you and 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

[Bisz István]

Hi Francesco,

> in hbide.prg please comment all the :destroy() lines, there are a
> bunch together... I will try later...

I don't touched hbide.prg ???

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

[Bisz István]

Hi,

>> BTW, after applying all your patches and cleaning hbXBP and hbIDE 
>> code, where few objects were hanging around and few were wrongly 
>> implemented, I can now get two RTEs ( yes, it is strange but true, 2 RTEs
>> )
>> at the very end of hbIDE exit : 
>> Error BASE/1301 Object destructor failure: Reference to freed block.
>> Error BASE/1301 Object destructor failure: Reference to freed block.
>> 
>> and it is consistent and reproducable always.
>> 

> More observations.

> The errors above are reported if I enter and exit hbIDE in quick
succession.
> But if I keep open hbIDE for a couple of minutes ( without doing anything
or do whatever I want ) and then exit, it _does_not_ showup any RTE.

> I m guessing that some objects are still under _construction_ by Qt, and
those pointers are either locked or pretended as so by Qt and and hence GC
tries to free them. It is puzzling > > but it is. I believe that this
happens in cases when we are creating lists or tables containing large
entries.

> This update is just to inform you the latest findings.

Let's wait for an upload containing a variant of my wrapped fix and we will
see...

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

[Bisz István]

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

[Bisz István]

> 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] SF.net SVN: harbour-project:[11565] trunk/harbour

[Bisz István]

Hi,

During the 'demoxbp' tests, a GPF appears after a right click on 'Test B' SLE. 
I don’t know if this is a known error or not. In any case please find the error 
log below.

Best regards,
István

Application Internal Error - 
c:\Downloads\harbour\contrib\hbxbp\tests\demoxbp.exe
Terminated at: 2009.06.29 19:35:33
Unrecoverable error 6005: Exception error: 

Exception Code:C005
Exception Address:6A34151A
EAX:00310037  EBX:  ECX:6A40E0C6  EDX:0005
ESI:6A3BEB80  EDI:0022AFDC  EBP:0022B000
CS:EIP:001B:6A34151A  SS:ESP:0023:0022AEF8
DS:0023  ES:0023  FS:003B  GS:
Flags:00010202
CS:EIP: 8B 00 89 95 58 FF FF FF FF D0 89 85 3C FF FF FF
SS:ESP: 03061FC4 0022AFC8 0022B000 6517E2F4 0022AF54 030EBB48 0022AF88 
0022B084 0315D0C8 6A392AD0 0306C9A0 0022B084 6A341E60 65932C08 659FCFC4 0022AF68

C stack:
EIP: EBP:   Frame: OldEBP, RetAddr, Params...
6A34151A 0022B000   0022B110 655F0704 03061FC4 65A43C6A 03061F68 65A43C60 
 030EBB48 0022B0B4 0022B0B4
655F0704 0022B110   0022B1A0 655F2533 03061F68  0022B168  
  03061F68 0022B2F4
655F2533 0022B1A0   0022B2C0 6565BB80 030EBB48   030EBB48 
0022B1F4  0001 0001
6565BB80 0022B2C0   0022B370 6565BF76 030EBB48 0022BC50  6A34384B 
0022B314 0022B3C8 0022B310 0022B308
6565BF76 0022B370   0022B3F0 656147BB 030EBB48 0022BC50   
FFFD 000A 0022B6AE 0022B474
656147BB 0022B3F0   0022B5D0 6517BE0D 01E6EC30 0022BC38 63020401 0004 
  0022B430 0022B640
6517BE0D 0022B5D0   0022B6E0 65619244 01E6EC30 0022BC38 01D84268 0022B7D4 
 01E222E8 0022B610 
65619244 0022B6E0   0022B710 6510C85C 01E6EC30 0022BC38 0022BC38 65934574 
 0022B8A4 0011 01E6EC30
6510C85C 0022B710   0022BA80 6510E874 00DB12E8 01E6EC30 0022BC38 0022BC50 
0022BA58 65948811 0022B818 0022B7D8
6510E874 0022BA80   0022BB10 6A32856A 003A2CC0 01E6EC30 0022BC38 0022BAF8 
6510D940 0022BA48 0051 00DB13C8
6A32856A 0022BB10   0022BD70 6518C509 003A2CC0 01E6EC30 0022BC38 0022BBA0 
0022BC78 65ADC340 0022BC78 
6518C509 0022BD70   0022D850 6518E830 003F4D70 0022D808 0022BFF0 0022BCA0 
01D84B14   4008
6518E830 0022D850   0022D87C 77BFF8D2 008907E0 0205  01130048 
0205 DCBAABCD  0022D8CC
77BFF8D2 0022D87C   0022D8F4 77BFF794 6518D530 008907E0 0205  
01130048 7B4368A9 0022DAB8 0022DAB0
77BFF794 0022D8F4   0022D958 77C8  6518D530 008907E0 0205 
 01130048 00E31D0C 0001
77C8 0022D958   0022D968 77C00060 6518D530 
77C00060 0022D968   0022F808 6A35E7B1 0022DAB0 0022DAB0   
0001 0306CB50 0007 03070E04
6A35E7B1 0022F808   0022F838 65192AD0 00DB1578 0022F820 00530CD9 004D01A6 
   
65192AD0 0022F838   0022F878 6A327E78 00DB1578 0022F850 0022F87C 0048DC10 
 003A08DC 003A08FC 0047CD8D
6A327E78 0022F878   0022F8DC 004154A9 003FFFD0 0022F89C   
003A225C 0001  


Modules:
0x0040 0x001A1000 c:\Downloads\harbour\contrib\hbxbp\tests\demoxbp.exe
0x77A2 0x00127000 C:\Windows\system32\ntdll.dll
0x764F 0x000DB000 C:\Windows\system32\kernel32.dll
0x6A1C 0x002A5000 C:\Qt\2009.03\qt\bin\QtCore4.dll
0x775C 0x000C6000 C:\Windows\system32\ADVAPI32.DLL
0x765D 0x000C2000 C:\Windows\system32\RPCRT4.dll
0x6FBC 0x8000 C:\Qt\2009.03\qt\bin\mingwm10.dll
0x760D 0x000AA000 C:\Windows\system32\msvcrt.dll
0x7632 0x00144000 C:\Windows\system32\OLE32.dll
0x7742 0x0004B000 C:\Windows\system32\GDI32.dll
0x77BE 0x0009D000 C:\Windows\system32\USER32.dll
0x7618 0x0002D000 C:\Windows\system32\WS2_32.DLL
0x77B5 0x6000 C:\Windows\system32\NSI.dll
0x6510 0x00ACC000 C:\Qt\2009.03\qt\bin\QtGui4.dll
0x766A 0x00073000 C:\Windows\system32\COMDLG32.DLL
0x77B8 0x00058000 C:\Windows\system32\SHLWAPI.dll
0x7325 0x00085000 
C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.6001.18000_none_886786f450a74a05\COMCTL32.dll
0x7672 0x00B1 C:\Windows\system32\SHELL32.dll
0x77B6 0x0001E000 C:\Windows\system32\IMM32.DLL
0x761B 0x000C8000 C:\Windows\system32\MSCTF.dll
0x7771 0x0008D000 C:\Windows\system32\OLEAUT32.DLL
0x752F 0x00032000 C:\Windows\system32\WINMM.DLL
0x752B 0x00039000 C:\Windows\system32\OLEACC.dll
0x7343 0x00042000 C:\Windows\system32\WINSPOOL.DRV
0x7631 0x9000 C:\Windows\system32\LPK.DLL
0x7647 0x0007D000 C:\Windows\system32\USP10.dll
0x7511 0x0019E000 
C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6001.18000_none_5cdbaa5a083979cc\comctl32.dll
0x749B 0x0003F000 C:\Windows\system32\uxtheme.dll
0x68F0 0x00013000 C:\Qt\2009.03\qt\plugins\imageformats\qgif4.dll
0x6BDC 0x00014000 C:\Qt\2009.03\qt\plugins\imagefo

RE: [Harbour] SF.net SVN: harbour-project:[11704] trunk/harbour

[Bisz István]

Hi Pritpal,

Great job! Just a small contribution regarding 'XbpFontDialog'; the 'fixedOnly' 
does not filter the font list as it is expected:

Class XbpFontDialog()

Attribute:  EXPORTED
 Datatype:  Logical (.F.)

Description 

The instance variable :fixedOnly contains the default value .F. (false). This 
means that the "Name" combo box of the font dialog is not limited to fixed 
width fonts. To display only non-proportional fonts in the combo box, this 
instance variable must be set to .T. (true) before the method :create() is 
executed. 

Best regards,
István

-Original Message-
From: vouch...@users.sourceforge.net [mailto:vouch...@users.sourceforge.net] 
Sent: 2009. július 10. 17:40
To: harbour@harbour-project.org
Subject: [Harbour] SF.net SVN: harbour-project:[11704] trunk/harbour

Revision: 11704
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11704&view=rev
Author:   vouchcac
Date: 2009-07-10 15:39:48 + (Fri, 10 Jul 2009)

Log Message:
---
2009-07-10 08:31 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * harbour/contrib/hbxbp/Makefile
  * harbour/contrib/hbxbp/xbp.ch
  * harbour/contrib/hbxbp/xbpgeneric.prg
  * harbour/contrib/hbxbp/xbpwindow.prg
! Cleanups ad tweaks.

  + harbour/contrib/hbxbp/xbppresspace.prg
+ Started XbpPresSpace() class - skeleton only.

  + harbour/contrib/hbxbp/xbpprintdialog.prg
+ Implemented XbpPrintDialog() class. 
  Mostly working but has some differences with Xbase++ - a work-in-progress.

  + harbour/contrib/hbxbp/xbpprinter.prg
+ Implemented XbpPrinter() class. 
  Mostly working but has some differences with Xbase++ - a work-in-progress.
  Integrated with XbpPrintDialog()

  * harbour/contrib/hbxbp/tests/demoxbp.prg
+ Demonstration of XbpPrintDialog() and XbpPrinter() classes.
  Click on  toolbar button.

/*  I would request Xbase++ users to test the code under different 
permutations and combinations and please report the differences.
So far I have not received any support in this direction.
 */ 

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbxbp/Makefile
trunk/harbour/contrib/hbxbp/tests/demoxbp.prg
trunk/harbour/contrib/hbxbp/xbp.ch
trunk/harbour/contrib/hbxbp/xbpgeneric.prg
trunk/harbour/contrib/hbxbp/xbpwindow.prg

Added Paths:
---
trunk/harbour/contrib/hbxbp/xbppresspace.prg
trunk/harbour/contrib/hbxbp/xbpprintdialog.prg
trunk/harbour/contrib/hbxbp/xbpprinter.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] My tests with Qt 4.5.2 and Fedora 11

[Bisz István]

Hi,

 

My demoqt and demoxbp tests on Fedora 11 shows similar results with Marcos
results (demoqt runs; demoxbp crashes), see attachments containing the
demoxbp crash.

 

The crash as I see appears in hb_itemRelease () with error message: ***
glibc detected ***
/home/Istvan/Download/harbour/contrib/hbxbp/tests/demoxbp: free(): invalid
pointer: 0x00c4b29c ***

called from HbDbfModel::rowCount(QModelIndex const&) const ()

 

Best regards,

István Bisz

 

 

System: Linux 2.6.29.6-217.2.8.fc11.i686.PAE #1 SMP Sat Aug 15 01:07:59 EDT 
2009 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10601901
Selinux: Enforcing
Accessibility: Disabled
GTK+ Theme: Nodoka
Icon Theme: Fedora
GTK+ Modules: canberra-gtk-module, pk-gtk-module, gnomebreakpad

Memory status: size: 82567168 vsize: 82567168 resident: 29921280 share: 
20549632 rss: 29921280 rss_rlim: 18446744073709551615
CPU usage: start_time: 1251216426 rtime: 49 utime: 7 stime: 42 cutime:0 cstime: 
1 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from 
'/home/Istvan/Download/harbour/contrib/hbxbp/tests/demoxbp'

[?1034h[Thread debugging using libthread_db enabled]
0x0045b424 in __kernel_vsyscall ()
#0  0x0045b424 in __kernel_vsyscall ()
#1  0x001b0e53 in __waitpid_nocancel () from /lib/libc.so.6
#2  0x00a0c8ff in g_spawn_sync () from /lib/libglib-2.0.so.0
#3  0x00a0cc0c in g_spawn_command_line_sync () from /lib/libglib-2.0.so.0
#4  0x087903cc in ?? () from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so
#5  0x08790dc2 in ?? () from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so
#6  
#7  0x0045b424 in __kernel_vsyscall ()
#8  0x0013e7c1 in raise () from /lib/libc.so.6
#9  0x00140092 in abort () from /lib/libc.so.6
#10 0x0017cdad in __libc_message () from /lib/libc.so.6
#11 0x001832a1 in malloc_printerr () from /lib/libc.so.6
#12 0x04590e2d in hb_itemRelease () from /usr/lib/libharbour.so
#13 0x0807e25b in HbDbfModel::rowCount(QModelIndex const&) const ()
#14 0x01424e58 in QHeaderView::initializeSections() () from 
/usr/lib/libQtGui.so.4
#15 0x01424f8a in QHeaderView::reset() () from /usr/lib/libQtGui.so.4
#16 0x014107f8 in QAbstractItemView::qt_metacall(QMetaObject::Call, int, 
void**) () from /usr/lib/libQtGui.so.4
#17 0x0142539d in QHeaderView::qt_metacall(QMetaObject::Call, int, void**) () 
from /usr/lib/libQtGui.so.4
#18 0x00cd4c73 in QMetaObject::activate(QObject*, int, int, void**) () from 
/usr/lib/libQtCore.so.4
#19 0x00cd58d2 in QMetaObject::activate(QObject*, QMetaObject const*, int, 
void**) () from /usr/lib/libQtCore.so.4
#20 0x00d0e057 in QAbstractItemModel::modelReset() () from 
/usr/lib/libQtCore.so.4
#21 0x00cb8b7d in QAbstractItemModel::reset() () from /usr/lib/libQtCore.so.4
#22 0x080914aa in HB_FUN_QT_HBDBFMODEL_RESET ()
#23 0x045aef2f in hb_vmProc () from /usr/lib/libharbour.so
#24 0x0458102e in hb_vmExecute () from /usr/lib/libharbour.so
#25 0x045b200f in hb_vmDoBlock () from /usr/lib/libharbour.so
#26 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#27 0x045ac90e in hb___msgEvalInline () from /usr/lib/libharbour.so
#28 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#29 0x04583ed9 in hb_vmExecute () from /usr/lib/libharbour.so
#30 0x0807d43b in HB_FUN_XBPBROWSE_DOCONFIGURE ()
#31 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#32 0x04583ed9 in hb_vmExecute () from /usr/lib/libharbour.so
#33 0x0807d8db in HB_FUN_XBPBROWSE_ROWCOUNT ()
#34 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#35 0x04583ed9 in hb_vmExecute () from /usr/lib/libharbour.so
#36 0x0807d49b in HB_FUN_XBPBROWSE_SUPPLYINFO ()
#37 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#38 0x04583ed9 in hb_vmExecute () from /usr/lib/libharbour.so
#39 0x045b200f in hb_vmDoBlock () from /usr/lib/libharbour.so
#40 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#41 0x045ae8e3 in hb_vmEvalBlockV () from /usr/lib/libharbour.so
#42 0x0807e23f in HbDbfModel::rowCount(QModelIndex const&) const ()
#43 0x01424e58 in QHeaderView::initializeSections() () from 
/usr/lib/libQtGui.so.4
#44 0x01424f8a in QHeaderView::reset() () from /usr/lib/libQtGui.so.4
#45 0x01408149 in QAbstractItemView::setModel(QAbstractItemModel*) () from 
/usr/lib/libQtGui.so.4
#46 0x01425a1d in QHeaderView::setModel(QAbstractItemModel*) () from 
/usr/lib/libQtGui.so.4
#47 0x0143ca6b in QTableView::setModel(QAbstractItemModel*) () from 
/usr/lib/libQtGui.so.4
#48 0x080c80c7 in HB_FUN_QT_QABSTRACTITEMVIEW_SETMODEL ()
#49 0x045aef2f in hb_vmProc () from /usr/lib/libharbour.so
#50 0x0458102e in hb_vmExecute () from /usr/lib/libharbour.so
#51 0x045b200f in hb_vmDoBlock () from /usr/lib/libharbour.so
#52 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#53 0x045ac90e in hb___msgEvalInline () from /usr/lib/libharbour.so
#54 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#55 0x04583ed9 in hb_vmExecute () from /usr/lib/libharbour.so
#56 0x0807d4db in HB_FUN_XBPBROWSE_CREATE ()
#57 0x04584fd2 in hb_vmSend () from /usr/lib/libharbour.so
#58 0x04583ed9 in h

RE: [Harbour] My tests with Qt 4.5.2 and Fedora 11

[Bisz István]

Hi Viktor,

After your commit the demoxbp starts running, thank you. Maybe the attached
output produced by the demoxbp can help for further debugging.

Best regards,
István Bisz

-Original Message-
From: Viktor Szakáts [mailto:harbour...@syenar.hu] 
Sent: 2009. augusztus 25. 20:17
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] My tests with Qt 4.5.2 and Fedora 11

Thank you for the backtrace.

It's clearly my patch with had a mistake. I'll commit the fix ASAP.

Brgds,
Viktor

On 2009.08.25., at 8:11, Bisz István wrote:

> Hi,
>
> My demoqt and demoxbp tests on Fedora 11 shows similar results with  
> Marcos results (demoqt runs; demoxbp crashes), see attachments  
> containing the demoxbp crash.
>
> The crash as I see appears in hb_itemRelease () with error message:  
> *** glibc detected *** /home/Istvan/Download/harbour/contrib/hbxbp/ 
> tests/demoxbp: free(): invalid pointer: 0x00c4b29c ***
> called from HbDbfModel::rowCount(QModelIndex const&) const ()
>
> Best regards,
> István Bisz
>
>
> 
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour


[ist...@localhost tests]$ hbmk2 demoxbp
hbmk2: Processing local make script: hbmk.hbm  
hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg   
Harbour 2.0.0beta2 (Rev. 12324)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoxbp.prg'...
Lines 3323, Functions/Procedures 48
Generating C source output to 'demoxbp.c'... Done.
[ist...@localhost tests]$ ./demoxbp
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-background-color
Unknown property focus-ba

RE: [Harbour] My tests with Qt 4.5.2 and Fedora 11

[Bisz István]

Hi Pritpal,

The 'Unknown property focus-background-color' disappeared, thank you.  
The ' QFont::setPointSize: Point size <= 0 (0), must be greater than 0' appears 
when the Font Dialog is selected.

Best regards,
István Bisz

-Original Message-
From: Pritpal Bedi [mailto:bediprit...@hotmail.com] 
Sent: 2009. augusztus 25. 23:44
To: harbour@harbour-project.org
Subject: RE: [Harbour] My tests with Qt 4.5.2 and Fedora 11


Hi


Bisz István wrote:
> 
> Unknown property focus-background-color
> 

Can you check after :

Revision: 12325 
 
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12325&view=rev
Author:   vouchcac 
Date: 2009-08-25 21:41:13 + (Tue, 25 Aug 2009) 



> QFont::setPointSize: Point size <= 0 (0), must be greater than 0
> [ist...@localhost tests]$
> 

I am looking into this.
Thanks for pointing out abnormalities.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/My-tests-with-Qt-4.5.2-and-Fedora-11-tp25139484p25142683.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] Linux build errors

[Bisz István]

Hi,

 

The attachment contains the build results on CentOS 5.3. The build fails on
Fedora 11 also. On Vista Ultimate works perfectly. Please review.

 

Best regards,

István Bisz

 



b.log
Description: Binary data


e.log
Description: Binary data
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] demoxbp segfault in Fedora 11

[Bisz István]

Hi,

I just finished the demoxbp testing. It works without the mentioned error
with the latest commits and KDE qt-devel installed, but without QT SDK from
Trolltech site.

Best regards,
István 

-Original Message-
From: Lorenzo Fiorini [mailto:lorenzo.fior...@gmail.com] 
Sent: 2009. szeptember 4. 8:16
To: Harbour Project Main Developer List.
Subject: [Harbour] demoxbp segfault in Fedora 11

Using QT SDK from trolltech site ./demoxbp worked as expected.
Then I've installed distro's KDE and qt-dev and I always get at start:

Program received signal SIGSEGV, Segmentation fault.
0x006a9163 in strlen () from /lib/libc.so.6
...
(gdb) bt
#0  0x006a9163 in strlen () from /lib/libc.so.6
#1  0x00e2d04f in XSetCommand () from /usr/lib/libX11.so.6
#2  0x00e31aa1 in XSetWMProperties () from /usr/lib/libX11.so.6
#3  0x05a88128 in QWidgetPrivate::create_sys(unsigned long, bool, bool) ()
   from /usr/lib/libQtGui.so.4
#4  0x05a4b6b0 in QWidget::create(unsigned long, bool, bool) ()
   from /usr/lib/libQtGui.so.4
#5  0x05a477e6 in QWidgetPrivate::createWinId(unsigned long) ()
   from /usr/lib/libQtGui.so.4
#6  0x05a4b0a8 in QWidgetPrivate::setWindowTitle_helper(QString const&) ()
   from /usr/lib/libQtGui.so.4
#7  0x05a4b4e2 in QWidget::setWindowTitle(QString const&) ()
   from /usr/lib/libQtGui.so.4
#8  0x080c3fd1 in HB_FUN_ERRORNEW ()
#9  0x00d450ff in hb_vmProc () from /opt/harbour/lib/libharbour.so
#10 0x00d13e35 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#11 0x00d480ff in hb_vmDoBlock () from /opt/harbour/lib/libharbour.so
#12 0x00d17912 in hb_vmSend () from /opt/harbour/lib/libharbour.so
#13 0x00d429ce in hb___msgEvalInline () from /opt/harbour/lib/libharbour.so
#14 0x00d17912 in hb_vmSend () from /opt/harbour/lib/libharbour.so
#15 0x00d150ef in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#16 0x080770bb in HB_FUN_ERRORNEW ()
#17 0x080d45a0 in ?? ()
#18 0x0815ace0 in HB_FUN_ERRORNEW ()
#19 0x0008 in ?? ()
#20 0xbfffea5c in ?? ()
#21 0x08159c90 in HB_FUN_ERRORNEW ()
#22 0x081afae8 in ?? ()
#23 0xbfffea88 in ?? ()
#24 0x00d17912 in hb_vmSend () from /opt/harbour/lib/libharbour.so
Backtrace stopped: frame did not save the PC
(gdb)

using valgrind --tool=memcheck --leak-check=yes -v ./demoxbp &>
demoxbp.log I see:
...
==11511== Invalid read of size 1
==11511==at 0x4007668: strlen (mc_replace_strmem.c:242)
==11511==by 0x9AB04E: XSetCommand (in /usr/lib/libX11.so.6.2.0)
==11511==by 0x9AFAA0: XSetWMProperties (in /usr/lib/libX11.so.6.2.0)
==11511==by 0x5A88127: QWidgetPrivate::create_sys(unsigned long,
bool, bool) (in /usr/lib/libQtGui.so.4.5.2)
==11511==by 0x5A4B6AF: QWidget::create(unsigned long, bool, bool)
(in /usr/lib/libQtGui.so.4.5.2)
==11511==by 0x5A477E5: QWidgetPrivate::createWinId(unsigned long)
(in /usr/lib/libQtGui.so.4.5.2)
==11511==by 0x5A4B0A7:
QWidgetPrivate::setWindowTitle_helper(QString const&) (in
/usr/lib/libQtGui.so.4.5.2)
==11511==by 0x5A4B4E1: QWidget::setWindowTitle(QString const&) (in
/usr/lib/libQtGui.so.4.5.2)
==11511==by 0x80C3FD0: (within
/home/twfiorlo/workspace/harbour/contrib/hbxbp/tests/demoxbp)
==11511==by 0x43AE0FE: hb_vmProc (in
/opt/harbour/lib/libharbour-2.0.0.so)
==11511==by 0x437CE34: hb_vmExecute (in
/opt/harbour/lib/libharbour-2.0.0.so)
...

Is there anything we can do at hbqt side?

best regards,
Lorenzo


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] demoxbp segfault in Fedora 11

[Bisz István]

Hi,

Sorry I should correct me, the error mentioned by Lorenzo appears just in
the case when demoxbp is linked statically, the dynamic version works.

...
==20686== Memcheck, a memory error detector.
==20686== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==20686== Using LibVEX rev 1884, a library for dynamic binary translation.
==20686== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==20686== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==20686== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==20686== For more details, rerun with: -v
==20686== 
==20686== Invalid read of size 1
==20686==at 0x4007668: strlen (mc_replace_strmem.c:242)
==20686==by 0xAF604E: XSetCommand (in /usr/lib/libX11.so.6.2.0)
==20686==by 0xAFAAA0: XSetWMProperties (in /usr/lib/libX11.so.6.2.0)
==20686==by 0x30B9127: QWidgetPrivate::create_sys(unsigned long, bool,
bool) (in /usr/lib/libQtGui.so.4.5.2)
==20686==by 0x307C6AF: QWidget::create(unsigned long, bool, bool) (in
/usr/lib/libQtGui.so.4.5.2)
==20686==by 0x30787E5: QWidgetPrivate::createWinId(unsigned long) (in
/usr/lib/libQtGui.so.4.5.2)
==20686==by 0x307C0A7: QWidgetPrivate::setWindowTitle_helper(QString
const&) (in /usr/lib/libQtGui.so.4.5.2)
==20686==by 0x307C4E1: QWidget::setWindowTitle(QString const&) (in
/usr/lib/libQtGui.so.4.5.2)
==20686==by 0x80C55D0: HB_FUN_QT_QWIDGET_SETWINDOWTITLE (in
/home/Istvan/Download/harbour/contrib/hbxbp/tests/demoxbp)
==20686==by 0x811247E: hb_vmProc (in
/home/Istvan/Download/harbour/contrib/hbxbp/tests/demoxbp)
==20686==by 0x80E11B4: hb_vmExecute (in
/home/Istvan/Download/harbour/contrib/hbxbp/tests/demoxbp)
==20686==by 0x811547E: hb_vmDoBlock (in
/home/Istvan/Download/harbour/contrib/hbxbp/tests/demoxbp)
==20686==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==20686==
...
Unrecoverable error 6005:
...
Exception SIGSEGV at address 0x1
...
Called from QT_QWIDGET_SETWINDOWTITLE(0)
...
Called from (b)QWIDGET(0) in ../../../TQWidget.prg
...
Called from QMAINWINDOW:SETWINDOWTITLE(0) in ../../../TQWidget.prg
Called from XBPDIALOG:CREATE(0) in ../../../xbpdialog.prg
Called from GUISTDDIALOG(312) in demoxbp.prg
Called from BUILDADIALOG(117) in demoxbp.prg
Called from _BUILDADIALOG(104) in demoxbp.prg
Called from MAIN(95) in demoxbp.prg
...

Best regards,
István Bisz 

-Original Message-
From: Bisz István [mailto:istvan.b...@t-online.hu] 
Sent: 2009. szeptember 4. 19:01
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] demoxbp segfault in Fedora 11

Hi,

I just finished the demoxbp testing. It works without the mentioned error
with the latest commits and KDE qt-devel installed, but without QT SDK from
Trolltech site.

Best regards,
István 

-Original Message-
From: Lorenzo Fiorini [mailto:lorenzo.fior...@gmail.com] 
Sent: 2009. szeptember 4. 8:16
To: Harbour Project Main Developer List.
Subject: [Harbour] demoxbp segfault in Fedora 11

Using QT SDK from trolltech site ./demoxbp worked as expected.
Then I've installed distro's KDE and qt-dev and I always get at start:

Program received signal SIGSEGV, Segmentation fault.
0x006a9163 in strlen () from /lib/libc.so.6
...
(gdb) bt
#0  0x006a9163 in strlen () from /lib/libc.so.6
#1  0x00e2d04f in XSetCommand () from /usr/lib/libX11.so.6
#2  0x00e31aa1 in XSetWMProperties () from /usr/lib/libX11.so.6
#3  0x05a88128 in QWidgetPrivate::create_sys(unsigned long, bool, bool) ()
   from /usr/lib/libQtGui.so.4
#4  0x05a4b6b0 in QWidget::create(unsigned long, bool, bool) ()
   from /usr/lib/libQtGui.so.4
#5  0x05a477e6 in QWidgetPrivate::createWinId(unsigned long) ()
   from /usr/lib/libQtGui.so.4
#6  0x05a4b0a8 in QWidgetPrivate::setWindowTitle_helper(QString const&) ()
   from /usr/lib/libQtGui.so.4
#7  0x05a4b4e2 in QWidget::setWindowTitle(QString const&) ()
   from /usr/lib/libQtGui.so.4
#8  0x080c3fd1 in HB_FUN_ERRORNEW ()
#9  0x00d450ff in hb_vmProc () from /opt/harbour/lib/libharbour.so
#10 0x00d13e35 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#11 0x00d480ff in hb_vmDoBlock () from /opt/harbour/lib/libharbour.so
#12 0x00d17912 in hb_vmSend () from /opt/harbour/lib/libharbour.so
#13 0x00d429ce in hb___msgEvalInline () from /opt/harbour/lib/libharbour.so
#14 0x00d17912 in hb_vmSend () from /opt/harbour/lib/libharbour.so
#15 0x00d150ef in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#16 0x080770bb in HB_FUN_ERRORNEW ()
#17 0x080d45a0 in ?? ()
#18 0x0815ace0 in HB_FUN_ERRORNEW ()
#19 0x0008 in ?? ()
#20 0xbfffea5c in ?? ()
#21 0x08159c90 in HB_FUN_ERRORNEW ()
#22 0x081afae8 in ?? ()
#23 0xbfffea88 in ?? ()
#24 0x00d17912 in hb_vmSend () from /opt/harbour/lib/libharbour.so
Backtrace stopped: frame did not save the PC
(gdb)

using valgrind --tool=memcheck --leak-check=yes -v ./demoxbp &>
demoxbp.log I see:
...
==11511== Invalid read of size 1
==11511==  

RE: [Harbour] demoxbp segfault in Fedora 11

[Bisz István]

For demoxbp building I used the following command:

$ hbmk2 -trace demoxbp &>shared.txt

producing the output:

hbmk2: Processing local make script: hbmk.hbm

hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg

hbmk2: Harbour compiler command (internal):

(/usr/local/bin/harbour) -n2 demoxbp.prg -w3 -i/usr/local/include/harbour
-i.. -i../../hbqt
Harbour 2.0.0beta2 (Rev. 12403)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoxbp.prg'...
...
Lines 3336, Functions/Procedures 49
Generating C source output to 'demoxbp.c'... Done.
hbmk2: C compiler command:

gcc -c -O3  -I/usr/local/include/harbour -I.. -I../../hbqt demoxbp.c
/tmp/hbmk_1wvog5.c
hbmk2: Linker command:

gcc demoxbp.o hbmk_1wvog5.o   -lgpm -lhbxbp -lhbqt -lQtCore -lQtGui
-lQtNetwork -lQtWebKit -lsupc++ -lhbcplr -lhbdebug -lharbour  -odemoxbp
-L/usr/local/lib/harbour

This shared version works for me.

For static build in hbmk2 terminology I used the following command:

$ hbmk2 -trace -static demoxbp &>static.txt

producing the output:

hbmk2: Processing local make script: hbmk.hbm

hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg

hbmk2: Harbour compiler command (internal):

(/usr/local/bin/harbour) -n2 demoxbp.prg -w3 -i/usr/local/include/harbour
-i.. -i../../hbqt
Harbour 2.0.0beta2 (Rev. 12403)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoxbp.prg'...
...
Lines 3336, Functions/Procedures 49
Generating C source output to 'demoxbp.c'... Done.
hbmk2: C compiler command:

gcc -c -O3  -I/usr/local/include/harbour -I.. -I../../hbqt demoxbp.c
/tmp/hbmk_p5m66x.c
hbmk2: Linker command:

gcc demoxbp.o hbmk_p5m66x.o   -lgpm -lhbxbp -lhbqt -lQtCore -lQtGui
-lQtNetwork -lQtWebKit -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang
-lhbcpage -lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbusrrdd -lhbhsx -lhbsix
-lrddntx -lrddcdx -lrddfpt -lhbuddall -lrddnsx -lhbrtl -lhbvm -lhbmacro
-lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib -lm -ldl -lrt  -odemoxbp
-L/usr/local/lib/harbour

This build generates the mentioned error.

I tried to build a fullstatic build without any success:

$ hbmk2 -trace -fullstatic demoxbp &>fullstatic.txt

hbmk2: Processing local make script: hbmk.hbm

hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg

hbmk2: Harbour compiler command (internal):

(/usr/local/bin/harbour) -n2 demoxbp.prg -w3 -i/usr/local/include/harbour
-i.. -i../../hbqt
Harbour 2.0.0beta2 (Rev. 12403)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoxbp.prg'...
...
Lines 3336, Functions/Procedures 49
Generating C source output to 'demoxbp.c'... Done.
hbmk2: C compiler command:

gcc -c -O3  -I/usr/local/include/harbour -I.. -I../../hbqt demoxbp.c
/tmp/hbmk_37ktzv.c
hbmk2: Linker command:

gcc demoxbp.o hbmk_37ktzv.o   -lgpm -lhbxbp -lhbqt -lQtCore -lQtGui
-lQtNetwork -lQtWebKit -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang
-lhbcpage -lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbusrrdd -lhbhsx -lhbsix
-lrddntx -lrddcdx -lrddfpt -lhbuddall -lrddnsx -lhbrtl -lhbvm -lhbmacro
-lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib -lm -ldl -lrt  -static
-odemoxbp -L/usr/local/lib/harbour
/usr/bin/ld: cannot find -lgpm
collect2: ld returned 1 exit status
hbmk2: Error: Running linker. 1

gcc demoxbp.o hbmk_37ktzv.o   -lgpm -lhbxbp -lhbqt -lQtCore -lQtGui
-lQtNetwork -lQtWebKit -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang
-lhbcpage -lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbusrrdd -lhbhsx -lhbsix
-lrddntx -lrddcdx -lrddfpt -lhbuddall -lrddnsx -lhbrtl -lhbvm -lhbmacro
-lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib -lm -ldl -lrt  -static
-odemoxbp -L/usr/local/lib/harbour 


Best regards,
István

-Original Message-
From: Lorenzo Fiorini [mailto:lorenzo.fior...@gmail.com] 
Sent: 2009. szeptember 5. 11:03
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] demoxbp segfault in Fedora 11

On Sat, Sep 5, 2009 at 10:24 AM, Bisz István wrote:

> Sorry I should correct me, the error mentioned by Lorenzo appears just in
> the case when demoxbp is linked statically, the dynamic version works.

I've never tried to link statically ( as far as I'm concerned ).

I use: hbmk -n demoxbp -lhbxbp -lhbqt -lQtCore ...

best regards,
Lorenzo


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] demoxbp segfault in Fedora 11

[Bisz István]

Looks that the linking stops on the first not found static library:

hbmk2: Processing local make script: hbmk.hbm

hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg

hbmk2: Harbour compiler command (internal):

(/usr/local/bin/harbour) -n2 demoxbp.prg -w3 -i/usr/local/include/harbour
-i.. -i../../hbqt
Harbour 2.0.0beta2 (Rev. 12407)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoxbp.prg'...
...
Lines 3336, Functions/Procedures 49
Generating C source output to 'demoxbp.c'... Done.
hbmk2: C compiler command:

gcc -c -O3  -I/usr/local/include/harbour -I.. -I../../hbqt demoxbp.c
/tmp/hbmk_2bzah7.c
hbmk2: Linker command:

gcc demoxbp.o hbmk_2bzah7.o   -lhbxbp -lhbqt -lQtCore -lQtGui -lQtNetwork
-lQtWebKit -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage
-lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbusrrdd -lhbhsx -lhbsix -lrddntx
-lrddcdx -lrddfpt -lhbuddall -lrddnsx -lhbrtl -lhbvm -lhbmacro -lhbcplr
-lhbpp -lhbcommon -lhbpcre -lhbzlib -lm -ldl -lrt -lgpm  -static -odemoxbp
-L/usr/local/lib/harbour
/usr/bin/ld: cannot find -lQtCore
collect2: ld returned 1 exit status
hbmk2: Error: Running linker. 1

gcc demoxbp.o hbmk_2bzah7.o   -lhbxbp -lhbqt -lQtCore -lQtGui -lQtNetwork
-lQtWebKit -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage
-lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbusrrdd -lhbhsx -lhbsix -lrddntx
-lrddcdx -lrddfpt -lhbuddall -lrddnsx -lhbrtl -lhbvm -lhbmacro -lhbcplr
-lhbpp -lhbcommon -lhbpcre -lhbzlib -lm -ldl -lrt -lgpm  -static -odemoxbp
-L/usr/local/lib/harbour

Best regards,
István

-Original Message-
From: Viktor Szakáts [mailto:harbour...@syenar.hu] 
Sent: 2009. szeptember 5. 16:15
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] demoxbp segfault in Fedora 11

> $ hbmk2 -trace -fullstatic demoxbp &>fullstatic.txt
> /usr/bin/ld: cannot find -lgpm

Quite strange that it gets detected at build time, but
not at hbmk2 time. No idea how can that happen assuming
the same Linux installation for both sessions.

Anyhow it wouldn't work due to the removal of lib grouping
(at least I guess), I'll fix this.

Brgds,
Viktor



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] demoxbp segfault in Fedora 11

[Bisz István]

Hi Viktor,

Yes, it is normal to exclude the fulstatic case from shared, static and
fulstatic test cases. But back to the original issue, why have we different
behavior between shared and static builds? The same problem appears with
demoqt buils. It's time to go deeper in these issues.

Best regards,
István

-Original Message-
From: Viktor Szakáts [mailto:harbour...@syenar.hu] 
Sent: 2009. szeptember 5. 17:15
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] demoxbp segfault in Fedora 11

> Looks that the linking stops on the first not found static library:

This part is normal.

Brgds,
Viktor

> hbmk2: Processing local make script: hbmk.hbm
>
> hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg
>
> hbmk2: Harbour compiler command (internal):
>
> (/usr/local/bin/harbour) -n2 demoxbp.prg -w3 -i/usr/local/include/ 
> harbour
> -i.. -i../../hbqt
> Harbour 2.0.0beta2 (Rev. 12407)
> Copyright (c) 1999-2009, http://www.harbour-project.org/
> Compiling 'demoxbp.prg'...
> ...
> Lines 3336, Functions/Procedures 49
> Generating C source output to 'demoxbp.c'... Done.
> hbmk2: C compiler command:
>
> gcc -c -O3  -I/usr/local/include/harbour -I.. -I../../hbqt demoxbp.c
> /tmp/hbmk_2bzah7.c
> hbmk2: Linker command:
>
> gcc demoxbp.o hbmk_2bzah7.o   -lhbxbp -lhbqt -lQtCore -lQtGui - 
> lQtNetwork
> -lQtWebKit -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang - 
> lhbcpage
> -lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbusrrdd -lhbhsx -lhbsix - 
> lrddntx
> -lrddcdx -lrddfpt -lhbuddall -lrddnsx -lhbrtl -lhbvm -lhbmacro - 
> lhbcplr
> -lhbpp -lhbcommon -lhbpcre -lhbzlib -lm -ldl -lrt -lgpm  -static - 
> odemoxbp
> -L/usr/local/lib/harbour
> /usr/bin/ld: cannot find -lQtCore
> collect2: ld returned 1 exit status
> hbmk2: Error: Running linker. 1
>
> gcc demoxbp.o hbmk_2bzah7.o   -lhbxbp -lhbqt -lQtCore -lQtGui - 
> lQtNetwork
> -lQtWebKit -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang - 
> lhbcpage
> -lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbusrrdd -lhbhsx -lhbsix - 
> lrddntx
> -lrddcdx -lrddfpt -lhbuddall -lrddnsx -lhbrtl -lhbvm -lhbmacro - 
> lhbcplr
> -lhbpp -lhbcommon -lhbpcre -lhbzlib -lm -ldl -lrt -lgpm  -static - 
> odemoxbp
> -L/usr/local/lib/harbour
>
> Best regards,
> István
>
> -Original Message-
> From: Viktor Szakáts [mailto:harbour...@syenar.hu]
> Sent: 2009. szeptember 5. 16:15
> To: Harbour Project Main Developer List.
> Subject: Re: [Harbour] demoxbp segfault in Fedora 11
>
>> $ hbmk2 -trace -fullstatic demoxbp &>fullstatic.txt
>> /usr/bin/ld: cannot find -lgpm
>
> Quite strange that it gets detected at build time, but
> not at hbmk2 time. No idea how can that happen assuming
> the same Linux installation for both sessions.
>
> Anyhow it wouldn't work due to the removal of lib grouping
> (at least I guess), I'll fix this.
>
> Brgds,
> Viktor
>
>
>
> ___
> 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

[Harbour] 'sqlite3' is skipped in clean phase, but isn't skipped in install phase.

[Bisz István]

Hi,

 

A small glitch during the harbour build on CentOS 5.3 solved with export 
HB_INC_SQLITE3=no.

 

During the make clean the sqlite3 is skipped:

 

! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org

! MAKE: make 3.81 /bin/sh clean  

! HB_HOST_PLAT: linux  HB_SHELL: sh

! HB_PLATFORM: linux (autodetected)

! HB_COMPILER: gcc (autodetected: /usr/bin/)

! Component: 'openssl' found in /usr/include

! Component: 'gpm' found in /usr/include

! Component: 'slang' found in /usr/include/slang

! Component: 'curses' found in /usr/include

! Component: 'x11' found in /usr/include

! Component: 'wattcp/watt-32' not supported on linux platform

! HB_INSTALL_PREFIX automatically set to: /usr/local

! REVISION: 12452

! 'gtdos' library skipped 

! 'gtgui' library skipped 

! 'gtos2' library skipped 

! 'gtwin' library skipped 

! 'gtwvt' library skipped 

! 'gtwvg' library skipped 

! 'hbodbc' library skipped ('odbc' not found)

! 'hbwin' library skipped 

! 'gtalleg' library skipped ('allegro' not found)

! 'hbblat' library skipped 

! 'hbfbird' library skipped ('firebird' not found)

! 'hbfimage' library skipped ('freeimage' not supported on linux platform)

! 'hbmysql' library skipped ('mysql' not found)

! 'hbpgsql' library skipped ('postgresql' not found)

! 'rddads' library skipped ('ads' not found)

! 'sddmy' library skipped ('mysql' not found)

! 'sddpg' library skipped ('postgresql' not found)

! 'sddfb' library skipped ('firebird' not found)

! 'sddodbc' library skipped ('odbc' not found)

! 'libpng' library skipped 

! 'sqlite3' library skipped (not supported or disabled)

 

But during the make install:

 

! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org

! MAKE: make 3.81 /bin/sh install  

! HB_HOST_PLAT: linux  HB_SHELL: sh

! HB_PLATFORM: linux (autodetected)

! HB_COMPILER: gcc (autodetected: /usr/bin/)

! Component: 'openssl' found in /usr/include

! Component: 'gpm' found in /usr/include

! Component: 'slang' found in /usr/include/slang

! Component: 'curses' found in /usr/include

! Component: 'x11' found in /usr/include

! Component: 'wattcp/watt-32' not supported on linux platform

! HB_INSTALL_PREFIX automatically set to: /usr/local

! REVISION: 12452

make[2]: Nothing to be done for `install'.

 

…

 

! 'hbodbc' library skipped ('odbc' not found)

gcc  -I. -I../../../../../include  -Wall -W -O3  -I/usr/include  -ohbsqlit3.o 
-c ../../../hbsqlit3.c

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_EXTENDED_RESULT_CODES’:

../../../hbsqlit3.c:443: warning: implicit declaration of function 
‘sqlite3_extended_result_codes’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_PREPARE’:

../../../hbsqlit3.c:741: warning: implicit declaration of function 
‘sqlite3_prepare_v2’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_BIND_ZEROBLOB’:

../../../hbsqlit3.c:1044: warning: implicit declaration of function 
‘sqlite3_bind_zeroblob’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_ENABLE_LOAD_EXTENSION’:

../../../hbsqlit3.c:1347: warning: implicit declaration of function 
‘sqlite3_enable_load_extension’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_RESET_AUTO_EXTENSION’:

../../../hbsqlit3.c:1363: warning: implicit declaration of function 
‘sqlite3_reset_auto_extension’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_BLOB_OPEN’:

../../../hbsqlit3.c:1568: error: ‘sqlite3_blob’ undeclared (first use in 
this function)

../../../hbsqlit3.c:1568: error: (Each undeclared identifier is reported only 
once

../../../hbsqlit3.c:1568: error: for each function it appears in.)

../../../hbsqlit3.c:1568: error: ‘ppBlob’ undeclared (first use in this 
function)

../../../hbsqlit3.c:1573: warning: implicit declaration of function 
‘sqlite3_blob_open’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_BLOB_CLOSE’:

../../../hbsqlit3.c:1603: error: ‘sqlite3_blob’ undeclared (first use in 
this function)

../../../hbsqlit3.c:1603: error: ‘pBlob’ undeclared (first use in this 
function)

../../../hbsqlit3.c:1603: error: expected expression before ‘)’ token

../../../hbsqlit3.c:1607: warning: implicit declaration of function 
‘sqlite3_blob_close’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_BLOB_BYTES’:

../../../hbsqlit3.c:1621: error: ‘sqlite3_blob’ undeclared (first use in 
this function)

../../../hbsqlit3.c:1621: error: ‘pBlob’ undeclared (first use in this 
function)

../../../hbsqlit3.c:1621: error: expected expression before ‘)’ token

../../../hbsqlit3.c:1625: warning: implicit declaration of function 
‘sqlite3_blob_bytes’

../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_BLOB_READ’:

../../../hbsqlit3.c:1639: error: ‘sqlite3_blob’ undeclared (first use in 
this function)

../../../hbsqlit3.c:1639: error: ‘pBlob’ undeclared (first use in this 
function)

../../../hbsqlit3.c:1639: error: expected expression before ‘)’ token

../../..

RE: [Harbour] 'sqlite3' is skipped in clean phase, but isn't skipped in install phase.

[Bisz István]

Hi,

sqlite.i386 3.3.6-2installed
sqlite-devel.i386   3.3.6-2installed

Best regards,
István Bisz

-Original Message-
From: Viktor Szakáts [mailto:harbour...@syenar.hu] 
Sent: 2009. szeptember 9. 15:15
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] 'sqlite3' is skipped in clean phase, but isn't skipped 
in install phase.

Hi,

The problem seems to be elsewhere. 'sqlite3' is probably not built in
either scenarios (although this part is actually missing from the second
log snippet included). The error seems to happen when building  
'hbsqlit3'
(the Harbour wrapper lib) and it suspiciously looks like errors due to
old sqlite3 headers, and missing guards from the wrapper code. Which  
version
of sqlite3 is provided on your CentOS system?

Brgds,
Viktor

On 2009.09.09., at 3:04, Bisz István wrote:

> Hi,
>
> A small glitch during the harbour build on CentOS 5.3 solved with  
> export HB_INC_SQLITE3=no.
>
> During the make clean the sqlite3 is skipped:
>
> ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
> ! MAKE: make 3.81 /bin/sh clean
> ! HB_HOST_PLAT: linux  HB_SHELL: sh
> ! HB_PLATFORM: linux (autodetected)
> ! HB_COMPILER: gcc (autodetected: /usr/bin/)
> ! Component: 'openssl' found in /usr/include
> ! Component: 'gpm' found in /usr/include
> ! Component: 'slang' found in /usr/include/slang
> ! Component: 'curses' found in /usr/include
> ! Component: 'x11' found in /usr/include
> ! Component: 'wattcp/watt-32' not supported on linux platform
> ! HB_INSTALL_PREFIX automatically set to: /usr/local
> ! REVISION: 12452
> ! 'gtdos' library skipped
> ! 'gtgui' library skipped
> ! 'gtos2' library skipped
> ! 'gtwin' library skipped
> ! 'gtwvt' library skipped
> ! 'gtwvg' library skipped
> ! 'hbodbc' library skipped ('odbc' not found)
> ! 'hbwin' library skipped
> ! 'gtalleg' library skipped ('allegro' not found)
> ! 'hbblat' library skipped
> ! 'hbfbird' library skipped ('firebird' not found)
> ! 'hbfimage' library skipped ('freeimage' not supported on linux  
> platform)
> ! 'hbmysql' library skipped ('mysql' not found)
> ! 'hbpgsql' library skipped ('postgresql' not found)
> ! 'rddads' library skipped ('ads' not found)
> ! 'sddmy' library skipped ('mysql' not found)
> ! 'sddpg' library skipped ('postgresql' not found)
> ! 'sddfb' library skipped ('firebird' not found)
> ! 'sddodbc' library skipped ('odbc' not found)
> ! 'libpng' library skipped
> ! 'sqlite3' library skipped (not supported or disabled)
>
> But during the make install:
>
> ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
> ! MAKE: make 3.81 /bin/sh install
> ! HB_HOST_PLAT: linux  HB_SHELL: sh
> ! HB_PLATFORM: linux (autodetected)
> ! HB_COMPILER: gcc (autodetected: /usr/bin/)
> ! Component: 'openssl' found in /usr/include
> ! Component: 'gpm' found in /usr/include
> ! Component: 'slang' found in /usr/include/slang
> ! Component: 'curses' found in /usr/include
> ! Component: 'x11' found in /usr/include
> ! Component: 'wattcp/watt-32' not supported on linux platform
> ! HB_INSTALL_PREFIX automatically set to: /usr/local
> ! REVISION: 12452
> make[2]: Nothing to be done for `install'.
>
> …
>
> ! 'hbodbc' library skipped ('odbc' not found)
> gcc  -I. -I../../../../../include  -Wall -W -O3  -I/usr/include  - 
> ohbsqlit3.o -c ../../../hbsqlit3.c
> ../../../hbsqlit3.c: In function â 
> €˜HB_FUN_SQLITE3_EXTENDED_RESULT_CODES’:
> ../../../hbsqlit3.c:443: warning: implicit declaration of function â 
> €˜sqlite3_extended_result_codes’
> ../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_PREPAREâ 
> €™:
> ../../../hbsqlit3.c:741: warning: implicit declaration of function â 
> €˜sqlite3_prepare_v2’
> ../../../hbsqlit3.c: In function ‘HB_FUN_SQLITE3_BIND_ZEROBLOBâ 
> €™:
> ../../../hbsqlit3.c:1044: warning: implicit declaration of function â 
> €˜sqlite3_bind_zeroblob’
> ../../../hbsqlit3.c: In function â 
> €˜HB_FUN_SQLITE3_ENABLE_LOAD_EXTENSION’:
> ../../../hbsqlit3.c:1347: warning: implicit declaration of function â 
> €˜sqlite3_enable_load_extension’
> ../../../hbsqlit3.c: In function â 
> €˜HB_FUN_SQLITE3_RESET_AUTO_EXTENSION’:
&g

RE: RE: [Harbour] 'sqlite3' is skipped in clean phase, but isn't skipped in install phase.

[Bisz István]

Hi Przemek,

I just want to signal a building problem with 'CentOS 5.3' based on 'RedHat 
Enterprise Linux 5.3'. Just to clarify the stability of the distribution. The 
RHEL is upgraded from 5.3 to 5.4 just in the last weeks. Yes, the 'sqlite' is 
quite "old", but is furnished by the RHEL 5.3 too. As I see our common goal is 
to maintain the compatibility at least with these stable releases too.

Best regards,
István

-Original Message-
From: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] 
Sent: 2009. szeptember 9. 19:53
To: Harbour Project Main Developer List.
Subject: Re: RE: [Harbour] 'sqlite3' is skipped in clean phase, but isn't 
skipped in install phase.

On Wed, 09 Sep 2009, Bisz István wrote:

Hi,

> sqlite.i386 3.3.6-2
> installed
> sqlite-devel.i386   3.3.6-2
> installed

It's quite old version.

If you have a while please try to update hbsqlit3.c code to work
with you SQLITE3 version, i.e. at line 441 we have:

   if( pHbSqlite3 && pHbSqlite3->db )
   {
  hb_retni( sqlite3_extended_result_codes(pHbSqlite3->db, hb_parl(2)) );
   }

change it to:

   if( pHbSqlite3 && pHbSqlite3->db )
   {
  /* TODO: verify exact SQLITE3 version in
   * which sqlite3_extended_result_codes() was added
   */
#if SQLITE_VERSION_NUMBER > 3003006
  hb_retni( sqlite3_extended_result_codes(pHbSqlite3->db, hb_parl(2)) );
#else
  hb_retni( -1 );
#endif
   }

3003006 is you SQLITE3. You can try to invest more time and check
exact SQLITE3 version in which some functions appeared, i.e. if
functions was intorduce im 3.4.0 then cahnge #if condition to:
   #if SQLITE_VERSION_NUMBER >= 3004000
otherwise use > instead of >= and leave TODO: note so other developers
will know that the exact SQLITE3 version was not precisely defined and
can update it in the future. If you send to us your modifications then
we can commit them to SVN or if you want then we can give you an account
so you can make it yourself.

best regards,
Przemek


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] demoxbp segfault in Fedora 11

[Bisz István]

Hi,

The segfault error is fixed with the a correction in QApplication.cpp, see 
below. The problem was with 'argc' passed to Qt by reference:

QApplication ( int & argc, char ** argv )

I just moved it out from the stack. Now the 'hbmk2 demoxbp' and 'hbmk2 -static 
demoxbp' builds are running. Tested until now on CentOS 5.3 with qtsdk-2009.03. 

Best regards,
István

Index: QApplication.cpp
===
--- QApplication.cpp(revision 12449)
+++ QApplication.cpp(working copy)
@@ -89,6 +89,9 @@
 static QApplication * app = NULL;
 static bool hbqtinit = false;
 
+int argc1;
+char ** argv1;
+
 /*
  * QApplication ( int & argc, char ** argv )
  * QApplication ( int & argc, char ** argv, bool GUIenabled )
@@ -129,15 +132,17 @@
 
 static void hbqt_Init( void * cargo )
 {
+/*
int argc;
char ** argv;
+*/
 
HB_SYMBOL_UNUSED( cargo );
 
-   argc = hb_cmdargARGC();
-   argv = hb_cmdargARGV();
+   argc1 = hb_cmdargARGC();
+   argv1 = hb_cmdargARGV();
 
-   app = new QApplication( argc, argv );
+   app = new QApplication( argc1, argv1 );
 
if( app )
   hbqtinit = true;
@@ -145,7 +150,7 @@
if( ! hbqtinit )
   hb_errInternal( 11001, "hbqt_Init(): QT Initilization Error.", NULL, 
NULL );
 
-   hb_cmdargInit( argc, argv );
+   hb_cmdargInit( argc1, argv1 );
 
hb_vmAtExit( hbqt_Exit, NULL );
 }


-Original Message-
From: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] 
Sent: 2009. szeptember 6. 12:46
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] demoxbp segfault in Fedora 11

On Sat, 05 Sep 2009, Szak�ts Viktor wrote:

Hi,

>> Yes, it is normal to exclude the fulstatic case from shared, static and
>> fulstatic test cases. But back to the original issue, why have we 
>> different
> I'm not sure I understand the issue here. I'd still be interested
> how can it happen that gpm is detected at build time but missing
> at hbmk2 time.

We do not link anything in core code using full static mode so we
do not know if it works.
I guess that gpm-devel is installed only with shared library and
libgpm.a is not installed.

>> behavior between shared and static builds? The same problem appears with
>> demoqt buils. It's time to go deeper in these issues.
> No idea, I hope someone will be able to give some hints.

Not all libraries are installed in static mode. Please also remember
that not all features can work in static mode so full static binaries
may not be fully functional.

best regards,
Przemek


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] demoxbp segfault in Fedora 11

[Bisz István]

Hi,

Confirmed on Fedora 11 with qt 4.5.2 as native package.

Both 'hbmk2 demoxbp' and 'hbmk2 -static demoxbp' builds are fully operational.
So the pointer to a variable resident temporary on the stack was the problem.

Best regards,
István 

-Original Message-----
From: Bisz István [mailto:istvan.b...@t-online.hu] 
Sent: 2009. szeptember 10. 13:52
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] demoxbp segfault in Fedora 11

Hi,

The segfault error is fixed with the a correction in QApplication.cpp, see 
below. The problem was with 'argc' passed to Qt by reference:

QApplication ( int & argc, char ** argv )

I just moved it out from the stack. Now the 'hbmk2 demoxbp' and 'hbmk2 -static 
demoxbp' builds are running. Tested until now on CentOS 5.3 with qtsdk-2009.03. 

Best regards,
István

Index: QApplication.cpp
===
--- QApplication.cpp(revision 12449)
+++ QApplication.cpp(working copy)
@@ -89,6 +89,9 @@
 static QApplication * app = NULL;
 static bool hbqtinit = false;
 
+int argc1;
+char ** argv1;
+
 /*
  * QApplication ( int & argc, char ** argv )
  * QApplication ( int & argc, char ** argv, bool GUIenabled )
@@ -129,15 +132,17 @@
 
 static void hbqt_Init( void * cargo )
 {
+/*
int argc;
char ** argv;
+*/
 
HB_SYMBOL_UNUSED( cargo );
 
-   argc = hb_cmdargARGC();
-   argv = hb_cmdargARGV();
+   argc1 = hb_cmdargARGC();
+   argv1 = hb_cmdargARGV();
 
-   app = new QApplication( argc, argv );
+   app = new QApplication( argc1, argv1 );
 
if( app )
   hbqtinit = true;
@@ -145,7 +150,7 @@
if( ! hbqtinit )
   hb_errInternal( 11001, "hbqt_Init(): QT Initilization Error.", NULL, 
NULL );
 
-   hb_cmdargInit( argc, argv );
+   hb_cmdargInit( argc1, argv1 );
 
hb_vmAtExit( hbqt_Exit, NULL );
 }


-Original Message-
From: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] 
Sent: 2009. szeptember 6. 12:46
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] demoxbp segfault in Fedora 11

On Sat, 05 Sep 2009, Szak�ts Viktor wrote:

Hi,

>> Yes, it is normal to exclude the fulstatic case from shared, static and
>> fulstatic test cases. But back to the original issue, why have we 
>> different
> I'm not sure I understand the issue here. I'd still be interested
> how can it happen that gpm is detected at build time but missing
> at hbmk2 time.

We do not link anything in core code using full static mode so we
do not know if it works.
I guess that gpm-devel is installed only with shared library and
libgpm.a is not installed.

>> behavior between shared and static builds? The same problem appears with
>> demoqt buils. It's time to go deeper in these issues.
> No idea, I hope someone will be able to give some hints.

Not all libraries are installed in static mode. Please also remember
that not all features can work in static mode so full static binaries
may not be fully functional.

best regards,
Przemek


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour