On 10 May 2013, at 03:19, Bruce Tulloch wrote:
The compiler turns such functions into procedures with an implicit
var-parameter
and the *caller* passes the location where the function result
should go
via that
parameter.
Okay, thanks, that clarifies, now I understand how a variable in the
On 05/09/2013 05:19 AM, Bruce Tulloch wrote:
This tells me that the test at the top of fpc_AnsiStr_Decr_Ref:
cmpl $0,(%eax)
jne .Ldecr_ref_continue
ret
.Ldecr_ref_continue:
passed (i.e. (%eax) was NOT nil) but sometime during the execution of
the following
El 09/05/2013 5:19, Bruce Tulloch escribió:
If there is no other explanation, then it means I need to find out how
the string variable referred to by (%eax) could have been been accessed
(or even known to exist) by any other thread in the same address space.--
Hello,
In the past I had
Thanks Ludo, but I know the value in (%eax) in this case is nil (see the
cpu register dump in my email) because the address of the string length (in
edx) is 0xfff8 (which is 8 less than nil) per the instruction just
before the one that fails with SEGV. The SEGV itself is caused by an
attempt
Thanks José, I can see that might cause a problem given bar passes result
by reference to foo without initializing result first. My question to Jonas
or others more knowledgeable than me about what the compiler does, is
whether result (in your example and my own case) is guaranteed to be
On 09 May 2013, at 14:39, Bruce Tulloch wrote:
Thanks José, I can see that might cause a problem given bar passes result
by reference to foo without initializing result first. My question to Jonas
or others more knowledgeable than me about what the compiler does, is
whether result (in your
On 09.05.2013 14:39, Bruce Tulloch wrote:
Thanks José, I can see that might cause a problem given bar passes
result by reference to foo without initializing result first. My
question to Jonas or others more knowledgeable than me about what the
compiler does, is whether result (in your example
The compiler turns such functions into procedures with an implicit
var-parameter
and the *caller* passes the location where the function result should go
via that
parameter.
Okay, thanks, that clarifies, now I understand how a variable in the
caller's scope can be affected while making
After a random but very long period of time (i.e. very many successful
calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref.
GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's
reference is to be decremented) is nil (i.e. 0x0).
Prima facie, that's the reason for the
On Wed, 8 May 2013, Bruce Tulloch wrote:
After a random but very long period of time (i.e. very many successful calls)
I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref.
GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is
to be decremented) is nil
On 08 May 2013, at 08:13, Bruce Tulloch wrote:
After a random but very long period of time (i.e. very many successful
calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref.
GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's
reference is to be decremented) is nil
Thanks Jonas, that confirms what I suspected. Next time I trap an instance
of this (rare) fault I will inspect exactly which CPU instruction raised
the SEGV inside fpc_AnsiStr_Decr_Ref in search of a source of memory
corruption.
Bruce.
On Wed, May 8, 2013 at 11:49 PM, Jonas Maebe
Michael, thanks for your feedback.
One thing that confuses me in light of Jonas' reply, if what you say is
correct (that local variables that have just come into scope are not
guaranteed to be nil) then assignment of Result := ''; at the first line of
foo may arbitrarily SEGV because
I've not managed to trap it again, but based on the information I have from
the last time it occurred I can say the error happened here:
--- a/rtl/i386/i386.inc
+++ b/rtl/i386/i386.inc
@@ -1523,7 +1523,7 @@
movl(%eax),%edx
subl$8,%edx
// [102] If l^0 then exit;
So here's some more diagnostic at the point of the SEGV:
(gdb) disass
Dump of assembler code for function _$SYSTEM$_Ll1637:
= 0x0118ace1 +0: cmpl $0x0,(%edx)
End of assembler dump.
(gdb) i reg
eax0xb6c77158 -1228443304
ecx0xb6c76c04 -1228444668
edx
15 matches
Mail list logo
