[fpc-devel] [Fwd: [Lazarus] Readig dbg files]
Hi I'm trying to create little tool which would do that : When exception is throw and stacktrace is returned from stripped exe I'd like to read stacktrace and convert it into lineinfo using appropriate dbg file which is not included in application given to users. Is there any already done tool for that ? I'm asking because I know there are many hidden tools in fcp directories :-) (like what dbugintf mentioned before) Boguslaw -- ___ Lazarus mailing list laza...@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SetPropValue case sensitive
Leonardo M. Ramé wrote: I studied a little deeper and the problem is (according to FPC 2.2.2 manual) that SetPropValue doesn't work because Variants are not implemented yet. The solution was easy, I used SetStrProp instead of SetPropValue. In my program all published properties were strings. Can you confirm if it is implemented in newer versions? Leonardo M. Ramé http://leonardorame.blogspot.com Hmm..I thought that variants were supported long time ago but my memory is bad. Are you sure about that ? Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] bugreports
Can someone assign those bugreports : http://bugs.freepascal.org/view.php?id=13499 and http://bugs.freepascal.org/view.php?id=13518 to proper person ? Thanks Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreports
Jonas Maebe wrote: On 29 Apr 2009, at 14:46, Jonas Maebe wrote: On 29 Apr 2009, at 14:38, Bogusław Brandys wrote: Can someone assign those bugreports : http://bugs.freepascal.org/view.php?id=13499 and http://bugs.freepascal.org/view.php?id=13518 to proper person ? In general, in FPC bug reports are not assigned to someone, but every developer for himself decides when and which bug reports to assign to himself. Some exceptions are documentation (Michael), database (Joost) and fcl-xml (Sergei). Low level or debugging win32 stuff is not one of those things though. The person who will eventually look at them is most likely Florian, but simply assigning the bugs to him is unlikely to speed up their resolution. Case in point: they might also be looked at by Yury, and in that case assigning them to Florian would probably delay their resolution. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel At least http://bugs.freepascal.org/view.php?id=13499 is really trivial Maybe it needs a little testing only, especially on win64 - if -Xg is supported there.Anyway it only affects windows platform. Thank you. Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreports
Micha Nelissen wrote: Bogusław Brandys wrote: Can someone assign those bugreports : http://bugs.freepascal.org/view.php?id=13499 and http://bugs.freepascal.org/view.php?id=13518 to proper person ? You must first request to be added as developer before we can assign the bug to you ;-P. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No thanks. It's too big honour for me ;-P Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is it possible to remove dependency on cygwin from freepascal ?
Marco van de Voort wrote: In our previous episode, sakesun roykiatisak said: For several years, some of Freepascal utilities always cause troubles from cygwin version conflict with my machine main cygwin installation. I believe Freepascal package will be a lot more integrated if those cygwin utilities can be replace with FPC-based solution. Have this idea been considered before ? How much effort to accomplish that ? Should I try to do that myself ? Afaik only GDB (both cmdline as in the textmode IDE) require cygwin. If these could be replaced with mingw versions, it would be cygwin-less. This can be seen below: C:\FPC\2.2.4\bin\i386-win32grep -i cygwin * Binary file cygiconv-2.dll matches Binary file cygncurses-8.dll matches Binary file cygwin1.dll matches Binary file fp.exe matches Binary file gdb.exe matches Mario Mahardhika already tried to do this, and put his experiences in the following bugreport: http://bugs.freepascal.org/view.php?id=11968 what needs to be done now is duplicate and evaluate this option, since one of the reasons fpc currently uses 6.2.1 is because that version was known to work the best. (afaik up to 6.4 has been tried). Interesting.I have : D:\FPC\2.3.2\bin\i386-win32fpc -i Free Pascal Compiler version 2.3.1 Compiler Date : 2009/04/27 Compiler CPU Target: i386 and: D:\FPC\2.3.2\bin\i386-win32grep -i cygwin * Binary file cygiconv-2.dll matches Binary file cygncurses-8.dll matches Binary file cygwin1.dll matches Binary file gdb.exe matches Only gdb.exe need replacement ? Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is it possible to remove dependency on cygwin from freepascal ?
Marco van de Voort wrote: In our previous episode, Bogusław Brandys said: Interesting.I have : D:\FPC\2.3.2\bin\i386-win32fpc -i Free Pascal Compiler version 2.3.1 Compiler Date : 2009/04/27 Compiler CPU Target: i386 and: D:\FPC\2.3.2\bin\i386-win32grep -i cygwin * Binary file cygiconv-2.dll matches Binary file cygncurses-8.dll matches Binary file cygwin1.dll matches Binary file gdb.exe matches Only gdb.exe need replacement ? The IDE can be compiled with and without gdb. Releases typically have GDB, snapshots not. oops,sorry. That was my mistake. I always make new snapshot from SVN and copy missing files from last release (which is used to compile SVN trunk version). So I guess there is no dependency on cygwin in SVN version ! Great ! The listed gdb.exe is really mingw32 based, I don't know why cygwin is an dependency here, but I moved cygwn libs to other diectory and gdb still works. Boguslaw. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [?? Probable Spam] Re: [fpc-devel] fpc map file
Daniël Mantione pisze: Op Sat, 18 Apr 2009, schreef Paul Ishenin: Daniël Mantione wrote: Can fpc team extend output made by -Xm with line info? Not if the GNU linker is used, which is the case for the majority of platforms. So -Xm is the same as ld -Map ? I thought -Xm map file is always fpc generated. No, the compiler has no knowledge which symbol is placed in which object location, so it cannot generate a map file by itself (unless the internal linker is used). Daniël Does it mean that at least it could work with internal linker under windows ? Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] function StabBackTraceStr(addr:Pointer):shortstring; - problem with subsequent back traces
There is a problem with this function. To avoid recursion there is a hack there to point BackTraceStrFunc to system implementation (which only shows addresses in hex).Long back trace which mostly ends with incorrect frame address as I suppose (OpenStabs is returning false for nil address) - thus function pointer is not returned back to lineinfo stabs processing method and next back trace contains only addresses . This problem is minor if program crashes with exception and stack trace but in other cases , like in bigger program (any Lazarus ones) , ONLY first back trace has useful information (source,line number) attached to it. That eliminates any useful logging like multilog for example. And nobody really is able to know correct stack frames length before calling any of such functions to obtain back trace (that would resolve problem). How we could fix it ? Is this recursion still a subject here ? I have one idea, probably not perfect. How about a function to initialize BackTraceStrFunc : TBackTraceStrFunc; The only way now is to set : BackTraceStrFunc := @SysBackTraceStr; (displays only hex of addresses) Something generic is needed, able to set to StabBackTraceStr if lineinfo unit (option -gl) is used and only to SysBackTraceStr in other case. It might be used also to set to user defined function. That way in any such functions in lcl (DumpExceptionBackTrace,GetStackTrace) or external package (like multilog), we could initialize BackTraceStrFunc to point again to correct function before obtaining stack trace. Boguslaw Brandys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Help with external dbg file and lineinfo
Hi, Please help me fix this bug: http://bugs.freepascal.org/view.php?id=13499 According to my little knowledge string table immediately follows symbol table so computation of string table in case of coff symbols is probably wrong by 4 bytes offset. Yet I don't understand why thos +4 was added here. There is of course not a complete fix, because I have no access to 64 bit windows. Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] A Compiled file size solution from the GBD mailing-list
Peter Vreman wrote:
Support for a separate .dbg file is now available for windows in
current svn trunk with the -Xg option. No need anymore for objcopy
--only-keep-debug objcopy --add-debug-link strip under
windows. The external linker (e.g. linux) still be updated to support
objcopy and strip when -Xg is passed.
I have just try on Windows with objcopy (I have ownloaded it from the
mingw binutils binaries) and works like a charm.
The -Xg flag do not works. GDB tell me: not found symbols.
PS: why do not add objcopy to the FPC bin folder?
Did you include the -g flag to generate debuginfo? The -Xg is a linker only
option that does not
influence generation of code or debuginfo. On an other system than the
development system it is
also working fine.
For windows we don't want to call external tools by default. The binutils are
very slow under
windows resulting in complains about slow compilation times which are infact
linking times. That
is also the reason why windows has already an internal linker.
[EMAIL PROTECTED] /fpc/compiler
$ ppc386 p -Xg -g
Free Pascal Compiler version 2.3.1-r9226 [2008/01/17] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Win32 for i386
Compiling p.pp
Linking p.exe
3 lines compiled, 0.1 sec, 23408 bytes code, 1040 bytes data
[EMAIL PROTECTED] /fpc/compiler
$ ls -l p.dbg p.exe
-rwx--+ 1 PVreman 20960 Jan 17 10:48 p.dbg
-rwx--+ 1 PVreman 28191 Jan 17 10:48 p.exe
[EMAIL PROTECTED] /fpc/compiler
$ gdb p.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) l
1 begin
2 writeln('hello');
3 end.
(gdb) q
Oops..what I did wrong ? Look below
D:\fpc -Xg -g p.pas
Free Pascal Compiler version 2.3.1 [2008/01/10] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Win32 for i386
Compiling p.pas
Linking p.exe
4 lines compiled, 0.1 sec, 23536 bytes code, 1032 bytes data
D:\gdb p.exe
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i686-pc-mingw32...(no debugging symbols found)
(gdb) l
No symbol table is loaded. Use the file command.
(gdb) quit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL StackTrace patch
Vincent Snijders wrote: Bogusław Brandys schreef: I think it should by default look for program.dbg file , and then if not exists for paramstr(0). Is that enough ? If so,please explain how to check if file exists , which function could be used here. No, as Peter described, you should look in the executable for a link to the file with debug info. Vincent I see - this is the perfect situation.I thought about fast hack ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] A Compiled file size solution from the GBD mailing-list
Michael Van Canneyt wrote: On Wed, 16 Jan 2008, Peter Vreman wrote: At 13:17 16-1-2008, you wrote: Marco van de Voort wrote: from _EXECUTABLE_ file FILE, iow you still need the unstripped exe. Perhaps it doesn't need the .text, .data, .bss etc sections though. I also posted this on Lazarus mailing list already. Below are the 2 commands to make it working. In the first command only the debug information is kept in lazarus.dbg. And the second is the already know way to strip the debug information. [cut] And as a final note: Yes, it is possible to fix fpc to write such a .dbg file also. Didn't we receive a patch from the Morfik people which did exactly this ? I remember that we had an email-conversation about it, and I also seem to remember applying a patch ? Michael. Could stack trace generation also have ability to use such .dbg file to create full stack trace instead of addresses only for stripped executable ? It would be similar to the C++ behavior. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debug Info proposal
Daniël Mantione wrote: Op Sun, 13 Jan 2008, schreef Joost van der Sluis: Op zaterdag 12-01-2008 om 20:11 uur [tijdzone +0100], schreef Bogus?aw Brandys: Jonas Maebe wrote: You can already do this: compile a release executable with debug info, and then distribute a stripped copy of that executable. The addresses in the stripped executable will match exactly with the addresses in the unstripped one. Jonas___ Wow! Great! Could fpc devel team provide application with source code which could translate addresses from bare bone stacktrace generated from stripped executable into full stacktrace with unit/line info using bare bone stacktrace file and executable with debug info included ? Why would we? This is exactly what strip does! It strips out the debug-info to a seperate file. This is wat the -debug package is when you create a .rpm. That -debug package stores the debuginfo. If you install the -debug package, you can use gdb to debug your application. If you don't install it, you can't. To be honest, if you would receive a runtime error + stack backtrace output from a user, converting it back to a source line back trace isn't that easy currently. Sure, you can load the debuginfo executable in gdb, then look up the lines one by one, but it would be a time consuming process. Daniël Daniel, This is exactly what I mean.I need to be able to distribute stripped executable and yet be able to convert stacktrace provided by user to the source line info back again. I don't want the user to know where my program failed (unit name and line info).A tool doing this instantly could be appreciated. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debug Info proposal
Daniël Mantione wrote: Op Sat, 12 Jan 2008, schreef Fabio Dell'Aria: I think the FreePascal debug info contains the full source code of the compiled software, Your assumption is incorrect. The debug info contains * Line info (which source code line belongs to which memory address). * Type info (information about Pascal data types) * Variable info (which variable is stored where) So will be possible: 1)...speedup the compiling process (write less bytes on disk and use less RAM to generate compiled file); 2)...the beginner programmers do not stop to uses FreePascal for its BIG compiled files. What do you think of this my proposal? Not possible. Free Pascal's debug information also has to conform to stabs/dwarf specification (the debugger has to understand it), so there is not much freedom to make changes how FPC writes debug information. Daniel Could we have debug info as separate file ? If this would be possible I could create release stripped EXE and yet be able to obtain unit/line of exception combining stacktrace numeric output with correct debug info file Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debug Info proposal
Jonas Maebe wrote: On 12 Jan 2008, at 16:07, Bogusław Brandys wrote: Could we have debug info as separate file ? If this would be possible I could create release stripped EXE and yet be able to obtain unit/line of exception combining stacktrace numeric output with correct debug info file You can already do this: compile a release executable with debug info, and then distribute a stripped copy of that executable. The addresses in the stripped executable will match exactly with the addresses in the unstripped one. Jonas___ Wow! Great! Could fpc devel team provide application with source code which could translate addresses from bare bone stacktrace generated from stripped executable into full stacktrace with unit/line info using bare bone stacktrace file and executable with debug info included ? Would be perfect situation to tidy join bare bone stacktrace and debug info to avoid combining stacktrace with incorrect debug executable.Maybe some magic number in stacktrace and debug info ? Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Invalid field size : 8
Hello,
I'm trying to work with InstantObjects using Free Pascal but I
encountered strange exception which is generated when I'm trying to
retrieve persistent class from Firebird 2.0 database.
Below is and extended output of stack trace (I've also turned on dsdebug
to watch all possible informations plus I;ve added a few lines to
fields.inc).
As you can see problem is with setting TField.Size to 8 for ftInteger
field , but I've also modified code to force Size of ftInteger to 4 and
error still persisted.
I've found that exception is generated inside this method of fields.inc:
class procedure TField.CheckTypeSize(AValue: Longint);
begin
If (AValue0) and Not IsBlob Then
DatabaseErrorFmt(SInvalidFieldSize,[AValue]);
end;
questions:
Is that a bug inside fields.inc or just a calling layer must prepare
TFieldDef to avoid this exception ? Is that a known problem ?
Regards
Boguslaw Brandys
D:\projekty\instantobjects\svn_io\Demos\test1flamenco
TLCLComponent.NewInstance WARNING: missing FWidgetSetClass TScreen
Before: INSERT INTO Contact (Address , CategoryClass, CategoryId , City
, Name ,
Phones , Class , Id , UpdateCount ) VALUES (:Address , :CategoryClass,
:Categor
yId , :City , :Name , :Phones , :Class , :Id , :UpdateCount )
Class: ftString = TContact
Id: ftString = 8E41F46CE1991E459939352E950F7661
UpdateCount: ftInteger = 1
Address: ftMemo = TAddressCity/City/TAddress
CategoryClass: ftString = TCategory
CategoryId: ftString = CAT000
City: ftString =
Name: ftString = Testowy1
Phones: ftMemo =
TInstantSQLResolver.InternalRetrieveMap Params.Count=0
TInstantSQLResolver.InternalRetrieveMap AObject.ClassName=TContact
Before: SELECT Address , CategoryClass, CategoryId , City , Name ,
Phones , Upda
teCount FROM Contact WHERE Class = :Class AND Id = :Id
Class: ftString = TContact
Id: ftString = 8E41F46CE1991E459939352E950F7661
TFieldDef.Create : ADDRESS(1)
TFieldDef.Create : CATEGORYCLASS(2)
TFieldDef.Create : CATEGORYID(3)
TFieldDef.Create : CITY(4)
TFieldDef.Create : NAME(5)
TFieldDef.Create : PHONES(6)
TFieldDef.Create : UPDATECOUNT(7)
Creating fields
Count : 7
Def 0 : ADDRESS(1)
Def 1 : CATEGORYCLASS(2)
Def 2 : CATEGORYID(3)
Def 3 : CITY(4)
Def 4 : NAME(5)
Def 5 : PHONES(6)
Def 6 : UPDATECOUNT(7)
About to create fieldADDRESS
Creating field ADDRESS
1
2
3
4
5
6
7
8
FieldNo= 1
Field.Size= 8
Attempt to SetFieldType
After SetFieldType
TFieldDef.CReateField : Trying to set dataset
TFieldDef.CReateField : Result Fieldno : 1 Self : 1
Setting dataset
About to create fieldCATEGORYCLASS
Creating field CATEGORYCLASS
1
2
3
4
5
6
7
8
FieldNo= 2
Field.Size= 32
Attempt to SetFieldType
After SetFieldType
TFieldDef.CReateField : Trying to set dataset
TFieldDef.CReateField : Result Fieldno : 2 Self : 2
Setting dataset
About to create fieldCATEGORYID
Creating field CATEGORYID
1
2
3
4
5
6
7
8
FieldNo= 3
Field.Size= 32
Attempt to SetFieldType
After SetFieldType
TFieldDef.CReateField : Trying to set dataset
TFieldDef.CReateField : Result Fieldno : 3 Self : 3
Setting dataset
About to create fieldCITY
Creating field CITY
1
2
3
4
5
6
7
8
FieldNo= 4
Field.Size= 30
Attempt to SetFieldType
After SetFieldType
TFieldDef.CReateField : Trying to set dataset
TFieldDef.CReateField : Result Fieldno : 4 Self : 4
Setting dataset
About to create fieldNAME
Creating field NAME
1
2
3
4
5
6
7
8
FieldNo= 5
Field.Size= 50
Attempt to SetFieldType
After SetFieldType
TFieldDef.CReateField : Trying to set dataset
TFieldDef.CReateField : Result Fieldno : 5 Self : 5
Setting dataset
About to create fieldPHONES
Creating field PHONES
1
2
3
4
5
6
7
8
FieldNo= 6
Field.Size= 8
Attempt to SetFieldType
After SetFieldType
TFieldDef.CReateField : Trying to set dataset
TFieldDef.CReateField : Result Fieldno : 6 Self : 6
Setting dataset
About to create fieldUPDATECOUNT
Creating field UPDATECOUNT
1
2
3
SetBufListSize: -1
Freeing buffers :1
SetBufListSize: Final FBufferCount=0
TApplication.HandleException Error retrieving object
TContact('8E41F46CE1991E459
939352E950F7661'): Invalid field size : 8
Stack trace:
$0050DBB1 TINSTANTOBJECTSTORE__RETRIEVEOBJECT, line 7413 of
D:/projekty/inst
antobjects/svn_io/Source/Core/InstantPersistence.pas
$0050BDC3 TINSTANTOBJECT__RETRIEVE, line 6614 of
D:/projekty/instantobjects/
svn_io/Source/Core/InstantPersistence.pas
$0041C165 TMAIN__TEST, line 184 of mainunit.pas
$0041BA94 TMAIN__BUTTON2CLICK, line 58 of mainunit.pas
$0047E394 TCONTROL__CLICK, line 2024 of ./include/control.inc
$0048CEDF TBUTTONCONTROL__CLICK, line 57 of ./include/buttoncontrol.inc
$0048D495 TCUSTOMBUTTON__CLICK, line 185 of ./include/buttons.inc
$0048D931 TBUTTON__CLICK, line 326 of ./include/buttons.inc
$0048D64A TCUSTOMBUTTON__WMDEFAULTCLICKED, line 240 of
./include/buttons.inc
$004099B2
$004759E2 TWINCONTROL__WNDPROC, line 4696 of ./include/wincontrol.inc
$004EDA2B DELIVERMESSAGE, line 614 of win32proc.pp
$004D7C90 WINDOWPROC, line 2310 of
Re: [fpc-devel] daemonapp 100% cpu easting fix
Steve Howe wrote: Hello all, such as changing the sleep time. Would it hurt to make it virtual ? Is it really necessary to do polling (with or without sleep) here ? Avoiding polling in any case would improve the performance and reduce intrusiveness. On Windows you have alternatives such as someone posted in thread, but on Linux/Unix you must to do polling as far as know. Anyway polling with sleep will consume very few cpu, acts very well overall and it's more portable. Yes.On windows you could create event and wait for it to be signaled.This particularly move response for loop to the windows core and makes a huge difference in CPU usage. Good luck. Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] daemonapp 100% cpu easting fix
Michael Van Canneyt wrote: On Sat, 17 Nov 2007, Mattias Gaertner wrote: On Sat, 17 Nov 2007 10:12:30 -0200 Steve Howe [EMAIL PROTECTED] wrote: Hello all, While using the daemonapp.pp unit to code a daemon, I've found that applications that it eat 100% of the CPU. After tracking and debugging, I've found out that the problem is in the daemonapp's TDaemonThread.Execute() method: procedure TDaemonThread.Execute; begin If FDaemon.Start then begin FDaemon.Status:=csRunning; StartServiceExecute; if not FDaemon.Execute then begin While Not Terminated do CheckControlMessage(True); CheckControlMessage(False); end; end; end; The loop has no interval so it just consumes all free CPU. Then CheckControlMessage has a bug. The 'True' means it should wait for the next message. But I see no 'virtual' and no code in this function - strange (fpc 2.3.1). You are right, I committed the 'fix' as initially proposed, but moved it to the unix version of the CheckControlMessage; Checking for this message is not yet implemented on unix. The idea is to open a 'control' socket using simpleIPC and to check on this socket for a message. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Long time ago I had the same problem with delphi based NT service code which was using loop in ServiceMain procedure.Then I used such code : WaitForSingleObject(EndEvent,INFINITE); CloseHandle(EndEvent); then in a control procedure SetEvent(EndEvent) was used to signal end of execution (SERVICE_CONTROL_STOP and SERVICE_CONTROL_SHUTDOWN options) This trick is of course Windows only but it let me drop CPU usage from very high all the time to almost zero when working thread is not doing any CPU intensive task. Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
Daniël Mantione wrote: Op Sat, 3 Nov 2007, schreef Marco van de Voort: Florian Klaempfl schrieb: Ok, I'll ask next time this person to spent the weekend to fix windows installer scripts and assign to it the still open web download page, installer and install package bugs. I was never for the download system in the first place remember? In my opinion it can be a huge binary. I meant only the current download pages. Add: Each additional downloadble package increases deployment pain significantly. Just look at 9500, this problem exists for aeons, nobody cares. Probably, but is that really the problem with packages? Packages are a part of Delphi compat, and have been explicitely on the 2.x roadmap for years. And now we cancel it because the linux install installs the demoes in the wrong place, if not manually fixed? As far as I am concerned, nothing is against the implementation of packages as long as it is non-intrusive to FPC users and FPC developers. Putting something on the roadmap does not automatically mean it gets implemented, fore major features there has to be someone who has an interrest in that feature before it get implemented. Until now, it hasn't been the case. Daniël Please,do not mess fpc with packages , implement only those parts required for creating and maintaining packages by Lazarus team.Here packages are useful. Better is to implement native debugger library for fpc programs instead of using gdb which may be fine under linux but crashes too often here under windows. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] KOL for WinCE
Yury Sidorov wrote: Hello, Finally I got time to port KOL to WinCE. Project page at SourceForge: http://sourceforge.net/projects/kol-ce/ Most things works. Report any bugs to tracker at SourceForge. Empty form hello world application exe is only 44.5KB! Yury Sidorov. Nice.What about MCK for visual development ? I think that ability to compile under win32 (I have Delphi 5) then rebuild for WinCE would be wonderful. What is missing to achieve it ? Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] KOL for WinCE
Yury Sidorov wrote: From: Bogusław Brandys [EMAIL PROTECTED] Yury Sidorov wrote: Hello, Finally I got time to port KOL to WinCE. Project page at SourceForge: http://sourceforge.net/projects/kol-ce/ Most things works. Report any bugs to tracker at SourceForge. Empty form hello world application exe is only 44.5KB! Yury Sidorov. Nice.What about MCK for visual development ? I think that ability to compile under win32 (I have Delphi 5) then rebuild for WinCE would be wonderful. What is missing to achieve it ? It is possible already. Win32 MCK projects can be created in Delphi and recompiled for WinCE using FPC. That's great. I will look at possibility to port MCK to Lazarus... I would like to see rather a new KOL widgetset for Lazarus,but I don't know how to implement such and don't break KOL feature - small exe size. Thank you. Boguslaw Brandys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC dynamic libraries
Michael Van Canneyt wrote: On Thu, 8 Feb 2007, George Birbilis wrote: We need a version system. That's not something we need, but which most OS'es need (and don't provide, except for hacks like symlinks or different filenames). Moreover, it doesn't really solve much unless you like having 20 different versions of the same shared library on your system (which would more or less defeat the purpose of saving space, although it could still save memory if more than one FPC program is running at the same time). If I understand well what you mean, Vista has versioning of that kind, you can ask to see older versions of any file and restore the one you want. A small caveat is that for files that don't exist currently anymore (deleted) there's no GUI to get them (or one I haven't spotted yet) and you need to make a dummy file with same name, then right click it and go to Properties, then ask for the older versions (there's a special tab for that on the dialog). Not sure if the Basic version of Vista has this functionality available (I tried it with Vista Ultimate) If you meant having many libs of different version exist side-by-side, .NET runtime supports it, but Win32 itself doesn't Most unixes also have it. The point is that it kind of defeats the purpose. Having 20+ libraries called fpcrtl-xyz.dll (or fpcrtl.so.x.y.z on unixes) defeats the purpose of a shared library: saving disk and (more importantly) memory space by factoring out common code. If we'd know that the fpcrtl.so (or .dll) interface will stay the same in the next 5 years, it makes sense to distribute this. Since the interface changes still wildly, it's a bad idea. Look at Delphi packages: as soon as the interface of a package changes, you must re-compile all the binaries that use it. The same would be true for FPC. I can assure you this is a major headache when distributing apps. Michael. Is that so hard to use version system for rtl libraries ? I think that most of Lazarus end users will work with one fpc version and no other. Lazarus developers still need fpc SVN and here is required a way to fast rebuild lazarus with fpc rtl which is nothing more that we are doing all the time now ;-) End users sometimes will need to rebuild lazarus and fpc also if some critical bugs are fixed in fpc but : is it something extraordinary ? Am I missing something ? Regards Boguslaw Brandys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linking to C++
Jason P Sage wrote: Hello All, This may have been mentioned with different words already - but I'm getting the impression one should write a C++ handler API or thin layer for the C++ lib one wants to utilize. The idea being FPC would only link on standard calls that more or less ran the underlying C++ lib like a remote control car (if that makes sense). On the FPC side you would tell the thin layer what objects to make, and allow for passing information to and from individual instances of classes within the thin client, and invoking methods the same way. This doesn't seem ideal by any stretch of the imagination - and makes me think of ugly things in time's past like 32bit to 16bit thunking, but this kind of thin layer coding (an API ultimately) seems like it MAY be the best way to link to the various libraries out there. I'm thinking of gcc and Microsoft API's generally. Personally - regardless of the difficulties - I've had some pretty decent luck with FPC and using the headers that people have created for various libraries that are crucial - like mysql and odbc. If I had more time to mess around I'd be playing with Direct X and Open GL too. Regardless - I'm happy with it so far! I welcome any and all comments. Good Day Jason P Sage If libraries are using pure C then you are lucky.If C++ ,then the only reasonable way for me is a thin wrapper DLL(s) :-( Of course you can use perl/python or create own object parser (in FPC) to actually recognize current mangling of functions but as you know it's not enough.All depends of how C++ classes are structured.afaik Qt is using some kind of parser also but I don't know the details. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error: Unable to create reg.xml file
Graeme Geldenhuys wrote: Hi, I started getting this message in my Lazarus applications since the last 2 weeks. It happens very seldom, but still strange. I don't use xml files at all in my application and don't have a reference to a reg.xml in any of my code. The applications are run from my HOME directory where I have full read/write access. Anybody got some ideas? I used FPC 2.1.1 (lastest SVN) and Lazarus (lastest SVN) under Linux. Lazarus is compiled against the GTK1 widget set. My applications also use the GTK1 widget set. PS: I did a quick search of the FPC src directory and found one reference to reg.xml in the /src/fcl/inc/xregreg.inc file. TRegistry under Linux is simulated using XML file (this is afaik TXMLRegistry class inside) FPC 2.1.1 is a proper version for registry under Linux.2.0.4 had bugs here. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Com Port
Amir Aavani wrote: Hi, How can I read/write through Com port by Lazarus/FPC?! Yours, Amir Use SynaSer package: http://synapse.ararat.cz/ Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-wince errors
Vincent Snijders wrote: Michael Schnell schreef: I guess not much help is needed. Just open the Debugger Options and select GNU debugger through SSH (gdb), would be my first guess. Never done this though. Great (sorry for my being cynical :-[ ) ! So I gather that you are convinced that it does work as well PC-PC as PC-ARM (Linux and windows). Convinced about the cross compiling, optimistic about remote debugging possibilities . I'm sure I'm going to test this once the project is started. Looking forward to the test results. Vincent I would rather test this method : http://sources.redhat.com/gdb/current/onlinedocs/gdb_18.html#SEC163 instead of searching for ssh method. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML and encoding problems
Alexander Todorov wrote: Hello, I am developing an application in Lazarus that is multi platform. It has very strong usage of xml that contains contains cyrillic text (Bulgarian language). All xml feeds are UTF-8 encoding and is converted internaly using iconv (UTF-8 - CP1251 and vice versa) when needed. On Linux this is working very well, but on Windows it is not. I have iconv.pas and link to iconv.dll but the problem is that when a xml document is read from file / stream after that the contents of the document are not UTF-8 encoded and iconv fails. Attached is a simple program that reads a file and prints xml values. On Linux the result is : [EMAIL PROTECTED]:~/temp/utf$ ./project1 user=Тихомир Руменов Тотев This is correct. Tested with gnome-terminal on native Linux system and with Bitvise Tunelier ssh client for Windows. On Windows the result is : E:\TMP\utfproject1.exe user=N???N? ?аN╡?? N??╡?? This is not correct. I tried debugging this but couldn't find the problem. Compiled with Lazarus 0.9.14 / FPC 2.0.2. Please give some help / hints / workaround. This is very cruical for me ATM. Thanks. Result printed on console are not sufficient.Compare binary chunks, then later check for system locale support. Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TSqlite3Dataset under Fedora Core 4 problem
Hello, I'm newbie under Linux. I'm trying to test my application which is working with sqlite 3.3.4 database fine under Windows, but it generates error about 'incorect library' or something.So I started to test examples from FPC 2.0.2 official release and fillds example from db/sqlite give me Invalid sql error. I have changed only tSqliteDataset into tSqlite3Dataset. it is under Fedora Core 4 and sqlite 3.3.4 was compiled from source (make and make install under root account) Seems like a problem with libsqlite3.so library. sqlite3_open working fine but later any SQL against sqlite_master returns error (exception).At the same time sqlite3 command line tool is working fine on the same database (I suppose this tool is linked statically against libsqlite.a and was created using C) Does anybody have experience working with sqlite3 under Linux and fpc ? Can you help me? Regards Boguslaw ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows Defines
Felipe Monteiro de Carvalho wrote:
Hello,
I am working on the Windows CE Widgetset for Lazarus. There were some
defines on LCL like this:
{$ifdef win32}
do something windows specific
{$endif}
But I would like those to be executed for Windows CE also, so we
discovered that WINDOWS is defined for both on 2.1.x. Later we found
out that it isn´t defined on 2.0.2. MSWINDOWS is defined for win32 on
2.0.2 but isn´t defined for WinCE on 2.1.x. So there is no define for
both Win32 and wince that also works on 2.0.2.
Suggestions are appreciated.
thanks,
--
Felipe Monteiro de Carvalho
What about using {$ifdef win32} and for WinCE specific {$ifdef wince} ?
Regards
Boguslaw Brandys
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ActiveX
Hello, Is it possible now with FPC 2.0.2 or development version to use ActiveX control under Windows ? Is so - how stable is this solution or is it experimental ? I'd like to create DLL which will opaque ActiveX control into designed API and it seems a bit new area in FPC. Additionally : would it be not hard with FPC to register a callback to return some informations from DLL (a record read from cash register for example) ? Regards Boguslaw Brandys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with Threads
Felipe Monteiro de Carvalho wrote:
Hello,
I am having problems with a multi-threaded application. It crashes on
Windows. Upon startup the program creates a secondary thread with
CreateSuspended := True
Then, when pressing a button, the thread is resumed. I changed the
Execute method of the thread to find the problem. Now it is only:
procedure TMedidor.Execute;
begin
while (not Terminated) do
begin
Self.Suspend;
end;
end;
On Linux the program works perfectly, but on Windows it will load,
appear normal, but when I click the button it crashes!!
The button code is only: vMedidor.Resume;
I tryed to create a new empty program with just one button and see if
the problem happens, but seams not to happen. o.O the problem seams
only to happen on the whole program.
On linux I am using the cthreads unit. Should I use something special on
Win32??? I read about a {$THREADING ON} or something like that while
searching the archives.
any ideas??
The only thing I can think of right now is rewriting the program to use
Windows API to create the thread to try to find out if the program is my
project or TThread class.
thanks,
Felipe
PS: I am posting here because I posted on Lazarus mailling list and
was told to repost here because this is more of a FPC problem
PS2: I tested on two different configurations:
latest subversion lazarus + FPC2.0.0
latest subversion lazarus + latest subversion FPC 2.0.3
Regards
B.Brandys
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thread REVERT
Florian Klaempfl wrote: Ales Katona wrote: Please remove ALL of my win32 thread patches(not the stacksize ones Reverted. tho). Thanks to neli, I now know that ThreadFunc is not called directly by the OS, but my ThreadMain which already IS stdcall. My bug with threads was actualy cause by a -Ct (check stack) switch which in win32 always causes a runtime error 202 (stack overflow) because of the default value for stack size which is 0. So to sum it up, no patches required, bug is not a bug but a feature(the feature should get fixed IMO but I have no idea how stack checking works) Me neither, at least not in win32 threads :) Probably no stack checking required at all becuase windows does it. What about simply disabling such -Ct compiler switch (with nice error message) under Windows ? Or maybe it should do nothing under Windows ? Regards Boguslaw Brandys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] bugreport 4433
Hi, Is this incompatibility http://www.freepascal.org/bugs/edit.php3?ID=4433 now stable and not going to change in future versions of FPC (at least 2.0.2) ? Regards Boguslaw Brandys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
