Re: [fpc-pascal] Fw: last svn fpc laz when build
Is there a define to detect if the compiler supports 1,2 byte sets? I could use
something like {$IFNDEF 2_0}{$IFNDEF 2_1}{$IFNDEF 2_2} but maybe there is a
smarter solution.
Vincnet
- Original Message -
From: 刘治国
To: [EMAIL PROTECTED]
Sent: Wednesday, June 27, 2007 9:57 AM
Subject: last svn fpc laz when build
last svn fpc laz when build
erroer
IDECommands.pas(586,11) Error: Illegal type conversion: "Set Of TShiftStateEnum"
to "LongInt"
IDECommands.pas(586,38) Error: Illegal type conversion: "Set Of TShiftStateEnum"
to "LongInt"
IDECommands.pas(588,11) Error: Illegal type conversion: "Set Of TShiftStateEnum"
to "LongInt"
IDECommands.pas(588,38) Error: Illegal type conversion: "Set Of TShiftStateEnum"
to "LongInt"___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
On Tuesday 26 June 2007 17:26, Luca Olivetti wrote: > procedure TButlerPhone.Receive(s: string); > > so s is a parameter. > This procedure is called exclusively from > > procedure TStatusThread.Receive; > begin >FOwner.Receive(FData) > end; > > (FOwner is a TButlerPhone) > > which in turn is called only here: > >FData:=copy(buffer,i+2,L-1); >if buffer[i+L+1]=checksum(FData) then >begin > if not terminated then synchronize(@Receive); >end else Are you passing AnsiString types between threads? If that's the case try using shortstrings or make a local copy of the parameter. And *DO NOT* pass them to a C-library in any way! I had several problems doing that too (and I don't mean the obvious case if the string is changed in one thread while it's still accessed in the other). There also seemed to be some issues with the reference counting: if I passed a local AnsiString to a thread constructor as argument and left the routine then, this seemed to confuse the thread throwing SIGSEGVs occasionally. Making a copy of the string (means: assigning it to a field in the thread instance before and using this field from now on) inside the constructor solved this problem. BTW, using the "disassemble" function of gdb sometimes reveals where the unnamed routine really is, so for the > #3 0x08059bec in ?? () > No symbol table info available. "disassemble 0x8059bec" *might* help you invastigating the source of the problem further. HTH, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
On 27 jun 2007, at 08:13, Vinzent Hoefler wrote: There also seemed to be some issues with the reference counting: if I passed a local AnsiString to a thread constructor as argument and left the routine then, this seemed to confuse the thread throwing SIGSEGVs occasionally. Maybe the parameter was declared as const? In that case, the refcount of the ansistring you pass isn't increased, because the compiler interprets the const as "the ansistring will not be changed in any way as long as that constructor is running". If it's a value parameter, it should work fine (a var parameter obviously wouldn't work either). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
On Wednesday 27 June 2007 07:55, Jonas Maebe wrote: > On 27 jun 2007, at 08:13, Vinzent Hoefler wrote: > > There also seemed to be some issues with the reference > > counting: if I passed a local AnsiString to a thread constructor as > > argument and left the routine then, this seemed to confuse the > > thread throwing SIGSEGVs occasionally. > > Maybe the parameter was declared as const? I think so. I always do that. ;) > In that case, the refcount of the ansistring you pass isn't increased, Meaning that the string will be freed once I leave the routine that called the constructor? That would explain it for sure. Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
On 27 jun 2007, at 08:47, Vinzent Hoefler wrote: In that case, the refcount of the ansistring you pass isn't increased, Meaning that the string will be freed once I leave the routine that called the constructor? Yes. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
En/na Vinzent Hoefler ha escrit: On Tuesday 26 June 2007 17:26, Luca Olivetti wrote: procedure TButlerPhone.Receive(s: string); so s is a parameter. This procedure is called exclusively from procedure TStatusThread.Receive; begin FOwner.Receive(FData) end; (FOwner is a TButlerPhone) which in turn is called only here: FData:=copy(buffer,i+2,L-1); if buffer[i+L+1]=checksum(FData) then begin if not terminated then synchronize(@Receive); end else Are you passing AnsiString types between threads? yes and no: the synchronize should assure that TButlerPhone.Receive is called from the main thread, and TStatusThread will wait until completion of the call. If that's the case try using shortstrings or make a local copy of the parameter I'll try that (though I think it shouldn't be necessary) . And *DO NOT* pass them to a C-library in any way! Not even surrounded by PChar()? (now that I think of it, it could well be that the library is storing the pointer and using it later when it is no longer valid, let me checkno, it doesn't). I had several problems doing that too (and I don't mean the obvious case if the string is changed in one thread while it's still accessed in the other). There also seemed to be some issues with the reference counting: if I passed a local AnsiString to a thread constructor as argument and left the routine then, this seemed to confuse the thread throwing SIGSEGVs occasionally. Making a copy of the string (means: assigning it to a field in the thread instance before and using this field from now on) inside the constructor solved this problem. Do you mean like (absurd example, I know) TMyThread.Constructor(astring:string); begin FString:=astring; FNum:=StrToInt(FString); inherited create(false); end; instead of TMyThread.Constructor(astring:string); begin FNum:=StrToInt(astring); inherited create(false); end; again, I don't think it should be necessary if you're only going to use astring in the constructor. BTW, using the "disassemble" function of gdb sometimes reveals where the unnamed routine really is, so for the #3 0x08059bec in ?? () No symbol table info available. "disassemble 0x8059bec" *might* help you invastigating the source of the problem further. thanks, I'll give it a try, though the last time I used assembly language was with a Z80 when it was new ;-) Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
En/na Luca Olivetti ha escrit: BTW, using the "disassemble" function of gdb sometimes reveals where the unnamed routine really is, so for the #3 0x08059bec in ?? () No symbol table info available. "disassemble 0x8059bec" *might* help you invastigating the source of the problem further. thanks, I'll give it a try, though the last time I used assembly language was with a Z80 when it was new ;-) well, I tried (with a fresh core, so the addresses are different than the previous one, but the result is the same): Core was generated by `./botphone -c /home/luca/.linphonerc'. Program terminated with signal 11, Segmentation fault. #0 0x0805989a in SYSTEM_GETERRNO$$LONGINT () (gdb) bt #0 0x0805989a in SYSTEM_GETERRNO$$LONGINT () #1 0x080608f2 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN () #2 0x08060a30 in SYSTEM_SIGNALTORUNERROR$LONGINT$PSIGINFO$PUCONTEXT () #3 0x0805a09c in ?? () #4 0x000b in ?? () #5 0xb6b6619c in ?? () #6 0xb6b6621c in ?? () #7 0x000b in ?? () #8 0x in ?? () (gdb) disassemble 0x0805a09c Dump of assembler code for function SYSTEM_LINUX_RESTORE_RT: 0x0805a09c : mov$0xad,%eax 0x0805a0a1 : int$0x80 0x0805a0a3 : ret End of assembler dump. (gdb) disassemble 0x000b No function contains specified address. (gdb) disassemble 0xb6b6619c No function contains specified address. (gdb) disassemble 0xb6b6621c No function contains specified address. (gdb) disassemble 0x No function contains specified address. (gdb) Oh well, I can always run the program under "valgrind --tool=none" :-P Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
En/na Luca Olivetti ha escrit: En/na Cesar Romero ha escrit: Where S is initialized? I only see L initialized. []s Cesar Romero 442: L:=length(s); 443: if L<1 then exit; 444: case s[1] of so I can't see how it could possibly be uninitialized. nothwithstanding the fact that if length(s)<1 line 444 won't be executed, so the "uninitialized" should be flagged in line 442, I know that this chunk is inside procedure TButlerPhone.Receive(s: string); so s is a parameter. This procedure is called exclusively from procedure TStatusThread.Receive; begin FOwner.Receive(FData) end; (FOwner is a TButlerPhone) which in turn is called only here: FData:=copy(buffer,i+2,L-1); if buffer[i+L+1]=checksum(FData) then begin if not terminated then synchronize(@Receive); end else And another writeln confirms that L is 1 when valgrind complains, so the string is definitely initialized. Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
On Wed, 27 Jun 2007 19:38:03 +0200 Luca Olivetti <[EMAIL PROTECTED]> wrote: > En/na Luca Olivetti ha escrit: > > En/na Cesar Romero ha escrit: > >> Where S is initialized? > >> I only see L initialized. > >> > >> []s > >> > >> > >> Cesar Romero > >>> > >>> 442: L:=length(s); > >>> 443: if L<1 then exit; > >>> 444: case s[1] of > >>> > >>> so I can't see how it could possibly be uninitialized. > > > > nothwithstanding the fact that if length(s)<1 line 444 won't be > > executed, so the "uninitialized" should be flagged in line 442, I know > > that this chunk is inside > > > > procedure TButlerPhone.Receive(s: string); > > > > so s is a parameter. > > This procedure is called exclusively from > > > > procedure TStatusThread.Receive; > > begin > > FOwner.Receive(FData) > > end; > > > > (FOwner is a TButlerPhone) > > > > which in turn is called only here: > > > > FData:=copy(buffer,i+2,L-1); > > if buffer[i+L+1]=checksum(FData) then > > begin > >if not terminated then synchronize(@Receive); > > end else > > > > And another writeln confirms that L is 1 when valgrind complains, so the > string is definitely initialized. Did you write to that string or merely set its length using SetLength? Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
En/na Vincent Snijders ha escrit:
On Wed, 27 Jun 2007 19:38:03 +0200
Luca Olivetti <[EMAIL PROTECTED]> wrote:
En/na Luca Olivetti ha escrit:
En/na Cesar Romero ha escrit:
Where S is initialized?
I only see L initialized.
[]s
Cesar Romero
442: L:=length(s);
443: if L<1 then exit;
444: case s[1] of
so I can't see how it could possibly be uninitialized.
nothwithstanding the fact that if length(s)<1 line 444 won't be
executed, so the "uninitialized" should be flagged in line 442, I know
that this chunk is inside
procedure TButlerPhone.Receive(s: string);
so s is a parameter.
This procedure is called exclusively from
procedure TStatusThread.Receive;
begin
FOwner.Receive(FData)
end;
(FOwner is a TButlerPhone)
which in turn is called only here:
FData:=copy(buffer,i+2,L-1);
if buffer[i+L+1]=checksum(FData) then
begin
if not terminated then synchronize(@Receive);
end else
And another writeln confirms that L is 1 when valgrind complains, so the
string is definitely initialized.
Did you write to that string or merely set its length using SetLength?
The string was passed as a value parameter, coming from fdata:
FData:=copy(buffer,i+2,L-1) (buffer is a static array of char, FData is
a string, field of the class)
if buffer[i+L+1]=checksum(FData) then
synchronize(@receive) ->
TStatusThread.Receive;
begin
FOwner.Receive(FData)
procedure TButlerPhone.Receive(s: string);
L:=length(s);
writeln('>>> ',L); ---> to confirm, and it's
always >0
if L<1 then exit;
case s[1] of --> here valgrind complains
Anyway, I doubt the problems is here, it only strikes me that valgrind
complains.
Bye
--
Luca
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 6/22/07, Jonas Maebe <[EMAIL PROTECTED]> wrote: Resources patch: up to the Windows maintainers. And what do the Windows maintainers say? Considering that lazarus snapshots are now build with a patched fpc 2.1.5 (Vincent, correct me if I am wrong), and it is working fine here, maybe this could be reconsidered? Or, at least the release of 2.2.2 could be made on a shorter time frame then usual, as there are plans to release a Lazarus version with features that depend on that patch before the currently scheduled time for 2.2.2 (someone said it would be summer 2008, is that right?) I would like to find an agreement were all sides are happy. thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 27 Jun 2007, at 23:27, Felipe Monteiro de Carvalho wrote: before the currently scheduled time for 2.2.2 (someone said it would be summer 2008, is that right?) Nobody has said that in this thread afaics, and even if someone did that would be very unlikely to be right. The only estimates I have seen are "2008" and late 2007. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
