[fpc-pascal] clarification about StackBottom and StackLength in threaded programs and/or shared libraries
Hey, guys. I hate to crosspost but nobody answered me in fpc-devel so
I thought I'd try it here.
Here's my original email from
http://lists.freepascal.org/lists/fpc-devel/2012-May/028965.html
I've got a system which consists of a main program and a few shared
object libraries running under Linux. In a debugging routine I have, I
walk the stack and use BackTraceStrFunc to output the backtrace. The
code I use to do this I adopted from heaptrc.pp, which looks like
this:
===
{ retrieve backtrace info }
bp:=get_caller_frame(get_frame);
{ valid bp? }
if (bp>=StackBottom) and (bp<(StackBottom + StackLength)) then
for i:=1 to tracesize do
begin
pp^.calls[i]:=get_caller_addr(bp);
oldbp:=bp;
bp:=get_caller_frame(bp);
if (bp(StackBottom + StackLength)) then
break;
end;
===
However, I've found that in my .so, when the backtrace function runs
in the context of a new thread I've started up, sometimes I end up
breaking out of the for loop too soon, because of the
(bp>(StackBottom + StackLength)) check. If I "pad" the comparand on
the right hand side the equation (ie., testing bp>(StackBottom +
StackLength + 12 kilobytes or so)), then I get the full backtrace (and
the loop breaks out because (bphttp://lists.freepascal.org/lists/fpc-pascal/2009-November/023040.html)
you said "And keep in mind that it's only an approximation" when
referring to doing stack checking in dynamic libraries. Is the
calculation of StackBottom the approximation you're referring to? If
that is the case, is what I'm doing (checking bp>(StackBottom +
StackLength + someArbitraryPadICameUpWith)) the right thing to do, or
is there a better way to know when to stop walking the stack? Also,
doesn't this mean that since heaptrc does the same thing, it's going
to not necessarily get the entire backtrace (although tracesize would
limit it anyway)?
Thanks,
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fcl-passrc package question about source file and line number info
Greetings! I've been using fcl-passrc (PParser and PasTree) to create a tool to help me with coverage analysis. Using the example provided in the package directory as a starting point, I've created a tool which finds the "begin" line number for each function/procedure definition and inserts a line of code there to help me keep track which functions are called and which aren't in my coverage tests. I've got it working great and it's giving me some really useful information. I was looking at the idea of increasing my granularity by doing this for every code block rather than just once at the beginning of every function. However, as I'm descending down through the parse tree, I'm finding that most of the TPasImplBlock objects have empty SourceFilename values and SourceLinenumber is 0. TPasProcedure's TProcedureBody's TPasImplBlock has the source file/line number information set, but if I descend any lower than that the deeper TPasImplBlock do not. Could someone with insight into this area give me any idea of why this is? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
> Oversight, a bug. > I am currently working on the parser, I'll look into this. > Michael. Thanks, I appreciate it. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
Michael wrote: > Please check revision 21909. > I haven't done much testing, because I didn't get to the test cases for > statements yet. Michael, I grabbed what's currently up in the svn trunk under fcl-passrc. I am getting the source filename and line number information now, so that's great. I did notice one problem, though... when FreeAndNil'ing the TPasModule object returned from ParseSource, I am able to get it to segfault with a simple example. I dummied it down into this source file: == unit timelib; interface implementation var elapsedT : array [0..999] of int64; ic : longword; initialization for ic := low(elapsedT) to high(elapsedT) do begin elapsedT[ic] := 0; end; end. == If you run the test_parser program (which I actually had to tweak to get it to compile) with that little unit as input, you'll get a segfault when doing the FreeAndNil(M). I'll let you know if i run into anything else. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover On Thu, Jul 12, 2012 at 1:38 PM, Seth Grover wrote: >> Oversight, a bug. >> I am currently working on the parser, I'll look into this. >> Michael. > > Thanks, I appreciate it. > > -SG > > -- > This email is fiction. Any resemblance to actual events > or persons living or dead is purely coincidental. > > Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
I think I found another problem with the latest revision of fcl-passrc in svn trunk. Given this source file as input to the test_parser program: === unit timelib; interface implementation procedure SortIndexHashTable; begin try except if (h <> nil) then begin end; end; end; end. === I get this output: === $ ./test_parser timelib.pas Unit timelib; Interface Implementation Procedure SortIndexHashTable; begin try except if (h<>nil) then begin end; ; except if (h<>nil) then begin end; ; end; end; end. === I think it's going down through the except block twice... I don't know if this is a problem with test_parser.pp itself, or with the package. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
> I should have fixed both problems you found. Please test, rev 21922. > Michael. It did fix those problems, but there's still a problem in the release given the following unit with a finalization section: === unit testlib; interface implementation finalization if Assigned(hello) then begin end; end. === Same sort of issue, it segfaults in the FreeAndNil of the TPasModule. The problem with the double-parsed code in the except block appears to be fixed now, though. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
I ran into another problem scenario, dealing with $include'd files.
Given these two files:
==iputils.pas
unit iputils;
{$mode objfpc}{$H+}
interface
{$define IPv6_Types}
{$include ip.inc}
{$undef IPv6_Types}
{$define IPv6_Interface}
{$include ip.inc}
{$undef IPv6_Interface}
implementation
{$define IPv6_Implementation}
{$include ip.inc}
{$undef IPv6_Implementation}
end.
=
==ip.inc=
{$IFDEF IPv6_Types}
type IPv6Addr = array[0..15] of byte;
type IPv4Addr = longword;
{$ENDIF}
{$IFDEF IPv6_Interface}
function IsIPv4CompatibleIPv6Addr(const ipv6 : IPv6Addr) : boolean;
{$ENDIF}
{$IFDEF IPv6_Implementation}
function IsIPv4CompatibleIPv6Addr(const ipv6 : IPv6Addr) : boolean;
begin
result := false;
end;
{$ENDIF}
=
I get an error like this:
Syntax error at token "EOF" in file iputils.pas at line 21 column
-7202378 line:21 column:-7202378 file:iputils.pas
An unhandled exception occurred at $0046FCA1 :
EParserError : Syntax error at token "EOF" in file iputils.pas at line
21 column -7202378
$0046FCA1
$00475C0C
$00474C83
$00474C3B
$00474396
$004091A4 line 1913 of test_parser.pp
Thanks,
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
Also, it looks like it gets a segfault if you try to $include a file that can't be found. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
Michael, I pulled down your latest revision (21934) which did fix the
problems I had reported. Thanks!
I did find another one for you:
unit timelib;
{$mode objfpc}{$H+}
interface
implementation
procedure SmonthToCmonth (const sMonth : array of char;
const stDex : longword;
out cVal : longword);
begin
case sMonth[stDex] of
'J' : cVal := 0;
end;
end;
end.
Segfaults in the same way as the others, on the release.
Thanks,
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
> Works fine here. > Michael. Hm, that's odd. I'll do a clean pull and clean build and let you know. Thanks. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
Hm, it's still failing for me.
Here's what I get with test_parser from examples given this input:
===
unit timelib;
{$mode objfpc}{$H+}
interface
implementation
procedure SmonthToCmonth (const sMonth : array of char;
const stDex : longword;
out cVal : longword);
begin
case sMonth[stDex] of
'J' : cVal := 0;
end;
end;
end.
===
Here's the program output:
$ ./test_parser timelib.pas
Unit timelib;
Interface
Implementation
Procedure SmonthToCmonth(const sMonth: Array of Char; const stDex:
LongWord; out cVal: LongWord);
begin
case sMonth[stDex] of
'J': cVal:= 0;
end;
end;
end.
An unhandled exception occurred at $ :
EAccessViolation : Access violation
$
$00480B72 line 1872 of pastree.pp
$004854D3 line 2740 of pastree.pp
$00419892
$00480B72 line 1872 of pastree.pp
$00485186 line 2703 of pastree.pp
$00419892
$00480B72 line 1872 of pastree.pp
$00419892
$00485001 line 2672 of pastree.pp
$00419892
$004800AB line 1747 of pastree.pp
$00419892
$0047DF2E line 1425 of pastree.pp
$00484D5D line 2652 of pastree.pp
$00419892
$0047DFDB line 1436 of pastree.pp
Here's the GDB backtrace:
(gdb) bt
#0 0x in ?? ()
#1 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#2 0x77f965c0 in ?? ()
#3 0x0047d819 in RELEASE (this=0x77f965c0) at pastree.pp:1332
#4 0x00480b72 in DESTROY (this=0x77f96540, vmt=0x0) at
pastree.pp:1872
#5 0x004854d3 in DESTROY (this=0x77f96540, vmt=0x1) at
pastree.pp:2740
#6 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#7 0x77f96458 in ?? ()
#8 0x0047d819 in RELEASE (this=0x77f96540) at pastree.pp:1332
#9 0x00480b72 in DESTROY (this=0x77f964c0, vmt=0x0) at
pastree.pp:1872
#10 0x00485186 in DESTROY (this=0x77f964c0, vmt=0x1) at
pastree.pp:2703
#11 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#12 0x77fa6620 in ?? ()
#13 0x0047d819 in RELEASE (this=0x77f964c0) at pastree.pp:1332
#14 0x00480b72 in DESTROY (this=0x77f9e2e0, vmt=0x1) at
pastree.pp:1872
#15 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#16 0x0002 in ?? ()
#17 0x0047d819 in RELEASE (this=0x77f9e2e0) at pastree.pp:1332
#18 0x00485001 in DESTROY (this=0x77f86040, vmt=0x1) at
pastree.pp:2672
#19 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#20 0x77fa6400 in ?? ()
#21 0x0047d819 in RELEASE (this=0x77f86040) at pastree.pp:1332
#22 0x004800ab in DESTROY (this=0x77f961c0, vmt=0x1) at
pastree.pp:1747
#23 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#24 0x in ?? ()
#25 0x0047d819 in RELEASE (this=0x77f961c0) at pastree.pp:1332
#26 0x0047df2e in DESTROY (this=0x77fb6180, vmt=0x0) at
pastree.pp:1425
#27 0x00484d5d in DESTROY (this=0x77fb6180, vmt=0x1) at
pastree.pp:2652
#28 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#29 0x7fffe0d0 in ?? ()
#30 0x0047d819 in RELEASE (this=0x77fb6180) at pastree.pp:1332
#31 0x0047dfdb in DESTROY (this=0x77f96140, vmt=0x1) at
pastree.pp:1436
#32 0x00419892 in SYSTEM_TOBJECT_$__FREE ()
#33 0x006dd268 in U_SYSTEM_OUTPUT ()
#34 0x0044369e in SYSUTILS_FREEANDNIL$formal ()
#35 0x7fffe0d0 in ?? ()
#36 0x004099fa in main () at test_parser.pp:1985
I'm doing it in Linux compiling for x86_64. There wouldn't be any
problem with me using this package source (pastree, paswrite, pparser,
pscanner) with FPC 2.6.0 would there? I am using FPC 2.6.0, but just
compiling this one package from svn in trunk separately.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
> Fixed.
> It seems that using the heaptrc unit masks some access violations.
> Michael.
Good to know. That fix seemed to work, but there's an issue with
having an "else" in a case statement. If you remove the else it works.
==
unit timelib;
{$mode objfpc}{$H+}
interface
implementation
procedure testproc;
var
i : integer = 0;
begin
case i of
0 : begin
end;
else
end;
end;
end.
==
Probably a similar thing to the others you've fixed.
Thanks a lot. I hope this is helping. I'll keep running this over my
source files until we've found them all. :)
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fcl-passrc package question about source file and line number info
> Fixed, plus a couple of others as well. Revision 21942. > Thanks, it's a great help. > Michael. I pulled the latest this morning and ran it over my whole project (about 140 units, 600,000-ish lines of code) and didn't get any more segfaults and it seems like all the information I'm pulling out of the parse tree is correct. I'll let you know if I run into anything else with it. Thanks a lot! -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] another minor bug in fcl-passrc (for-in loop)
Michael, Greetings! I found another minor problem with the fcl-passrc parser. The new for-in string loop (http://wiki.freepascal.org/for-in_loop#String_loop) causes the parser to fail with 'Expected ":=" at token "in" in file ...'. Cheers, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: another minor bug in fcl-passrc (for-in loop)
Apologies, I should have looked at the latest changes before I emailed. I just saw "For in construct and class/record helpers implemented" you checked in a week ago, I'll grab that. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover On Wed, Aug 29, 2012 at 9:52 AM, Seth Grover wrote: > Michael, > > Greetings! I found another minor problem with the fcl-passrc parser. > > The new for-in string loop > (http://wiki.freepascal.org/for-in_loop#String_loop) causes the parser > to fail with 'Expected ":=" at token "in" in file ...'. > > Cheers, > > -SG > > -- > This email is fiction. Any resemblance to actual events > or persons living or dead is purely coincidental. > > Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] roadblock with Synapse and SNMPv3 authentication
I posted a similar email to the Synapse mailing list a while ago, but nobody ever replied so I thought I'd broaden my audience. Apologies if you're a member of both lists and have already read this. Also, before I go any further, I just want to make it totally clear that my *entire* understanding of SNMP comes from looking at the Synapse SNMP-related code and reading RFCs, so if I say something stupid, I'm not really stupid... just ignorant. :) I've made some additions to snmpsend.pas to allow implementation of an SNMP agent (server) which can do authentication (AuthNoPriv using MD5 and SHA1) of SNMP packets sent by SNMP clients. This code seems to work when both the server and the client are both written using FreePascal and Synapse. However, when I try to use another third-party SNMP library (particularly Net::SNMP with Perl) the same authentication code which works perfectly for Synapse-sent SNMP messages fails to authenticate the Net::SNMP-sent SNMP messages. I've kind of hit a brick wall with this. Since my authentication code works perfectly authenticating SNMP messages sent with the existing Synapse code, but not with messages from Net::SNMP, does that mean that there's something wrong with the existing Synapse code? Anyway, I was hoping that someone among the Synapse developers, or (now) someone else on the FreePascal mailing list would be willing to lend a second pair of eyes to this and help me figure out what I'm doing wrong. Here's a URL of a tarball containing what you need to duplicate what I'm doing: http://maemobox.org/tlacuache/snmpAuthTest.tar.gz This contains: - snmp-changes.patch = a patch generated against release 38 of the Synapse source code containing my modifications for SNMPv3 authentication - server = contains a small server program which listens for SNMP messages (traps and informrequests), authenticates them if needed and displays the contents - client = contains a test program for sending SNMP messages to the server (works perfectly for me with the server) - clientPerl = contains a perl script to send an SNMP message to the server (my server fails to authenticate it correctly) You should just be able to apply my patch to your synapse code and build the projects as-is (although I suppose you might need to change the unit search paths to point to the location of the synapse source code you patched). I'd certainly appreciate any help anyone could offer. Of course my hope is that all of the code I've written and anything else that comes from this could benefit the Synapse project and FPC community. Thanks, -SG ==== My eyes! The goggles do nothing! Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TProcess problem
I'm familiarizing myself with TProcess, so I decided to write a simple
routine which executes a command and puts STDOUT/STDERR in a
stringlist:
-
procedure ExecCommand(const command : string;
const stdout : TStringList;
const stderr : TStringList;
const timeoutSec : integer;
out exitStatus : integer);
const
READ_BYTES = 2048;
var
P: TProcess;
nOut : LongInt;
nErr : LongInt;
StdOutput : TMemoryStream;
StdOutBytesRead: LongInt;
StdError : TMemoryStream;
StdErrBytesRead: LongInt;
startTime : TDateTime;
begin
exitStatus := -1;
StdOutput := TMemoryStream.Create;
StdError := TMemoryStream.Create;
StdOutBytesRead := 0;
StdErrBytesRead := 0;
try
P := TProcess.Create(nil);
try
P.CommandLine := command;
P.Options := [poUsePipes];
startTime := now;
P.Execute;
{ read stderr and stdout while the process runs }
while P.Running do begin
StdOutput.SetSize(StdOutBytesRead + READ_BYTES);
StdError.SetSize(StdErrBytesRead + READ_BYTES);
nOut := P.Output.Read((StdOutput.Memory + StdOutBytesRead)^,
READ_BYTES);
if nOut > 0 then begin
Inc(StdOutBytesRead, nOut);
end;
nErr := P.Stderr.Read((StdError.Memory + StdErrBytesRead)^, READ_BYTES);
if nErr > 0 then begin
Inc(StdErrBytesRead, nErr);
end;
if (nErr = 0) and (nOut = 0) then Sleep(100);
if (timeoutSec > 0) and (SecondsBetween(now, startTime) >
timeoutSec) then begin
P.Terminate(exitStatus);
raise Exception.Create('Execution timed out');
end;
end;
exitStatus := P.ExitStatus;
{ read what's left over in stdout }
repeat
StdOutput.SetSize(StdOutBytesRead + READ_BYTES);
nOut := P.Output.Read((StdOutput.Memory + StdOutBytesRead)^,
READ_BYTES);
if nOut > 0 then begin
Inc(StdOutBytesRead, nOut);
end;
until nOut <= 0;
{ read what's left over in stderr }
repeat
StdError.SetSize(StdErrBytesRead + READ_BYTES);
nErr := P.Stderr.Read((StdError.Memory + StdErrBytesRead)^, READ_BYTES);
if nErr > 0 then begin
Inc(StdErrBytesRead, nErr);
end;
until nErr <= 0;
StdOutput.SetSize(StdOutBytesRead);
if Assigned(stdout) then begin
stdout.LoadFromStream(StdOutput);
end;
StdError.SetSize(StdErrBytesRead);
if Assigned(stderr) then begin
stderr.LoadFromStream(StdError);
end;
finally
FreeAndNil(StdOutput);
FreeAndNil(StdError);
FreeAndNil(P);
end;
except
on E : Exception do begin
exitStatus := -1;
if Assigned(stderr) then begin
stderr.Add(E.Message);
end;
end;
end;
end;
-
Everything works fine unless the output to STDOUT of the command
exceeds 65K (I'm testing it by running "cat /path/to/some/file" as the
command). When this happens, the P.Stderr.Read inside the while loop
just hangs and never returns.
What am I doing wrong?
-SG
====
Computer over. Virus = very yes.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: How to build .so with FPC and use it in C program?
I do it all the time. It works fine in Linux as of 2.2.2. There was a
problem in 2.2.0 where initialization and finalization code of units
in your uses section wouldn't get called, but they do now.
--- test.lpr ---
library test;
{$mode objfpc}{$H+}
uses
Classes, SysUtils;
function SquareNumber(const input : integer) : integer; cdecl;
begin
writeln('libtest.so SquareNumber');
result := input * input;
end;
exports
SquareNumber name 'SquareNumber';
begin
writeln('libtest.so initialization');
end.
--- ctest.c ---
#include
int SquareNumber(const int input);
main()
{
int input;
int output;
input = 4;
output = SquareNumber(4);
printf("%i squared is %i\n", input, output);
}
---
To build the .so:
fpc -Sgi -CX -Xs -XX -vewnhi -l -Fu. -olibtest.so test.lpr
To build the c program (make sure the .so is in your link path)
gcc -o ctest -ltest ctest.c
Then run it:
libtest.so initialization
libtest.so SquareNumber
4 squared is 16
-SG
====
Computer over. Virus = very yes.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] DateTimeToUnix bug?
I thought I'd get feedback here before I log this as a bug:
==
program Project1;
uses
Classes,
SysUtils,
DateUtils;
var
utime : longword;
currentDt : TDateTime;
convertedDt : TDateTime;
begin
currentDt := EncodeDateTime(1989, 9, 16, 12, 0, 0, 0);
utime := DateTimeToUnix(currentDt);
convertedDt := UnixToDateTime(utime);
writeln(FormatDateTime('mm/dd/ HH:nn:ss', currentDt) + ' = ' +
IntToStr(utime) + ' = ' +
FormatDateTime('mm/dd/ HH:nn:ss',
convertedDt));
currentDt := EncodeDateTime(1989, 9, 16, 12, 0, 1, 0);
utime := DateTimeToUnix(currentDt);
convertedDt := UnixToDateTime(utime);
writeln(FormatDateTime('mm/dd/ HH:nn:ss', currentDt) + ' = ' +
IntToStr(utime) + ' = ' +
FormatDateTime('mm/dd/ HH:nn:ss',
convertedDt));
currentDt := EncodeDateTime(1989, 9, 16, 12, 0, 2, 0);
utime := DateTimeToUnix(currentDt);
convertedDt := UnixToDateTime(utime);
writeln(FormatDateTime('mm/dd/ HH:nn:ss', currentDt) + ' = ' +
IntToStr(utime) + ' = ' +
FormatDateTime('mm/dd/ HH:nn:ss',
convertedDt));
end.
==
The output I get (fpc 2.2.2 on linux) is:
09-16-1989 12:00:00 = 621950400 = 09-16-1989 12:00:00
09-16-1989 12:00:01 = 621950400 = 09-16-1989 12:00:00
09-16-1989 12:00:02 = 621950402 = 09-16-1989 12:00:02
It seems to me that 09-16-1989 12:00:01 should be 621950401, not 621950400.
Is this broken or am I missing something?
-sg
Computer over. Virus = very yes.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] heap size growing
I've got a fairly large system (originally written in Delphi, then moved to Kylix, and now finally in FPC 2.2.2) which is doing a lot of different things. Various threads are running which execute reports, communiate with other devices, query data, process notifications, send and receive data on sockets, etc. For analysis of how its performing, I've got a thread which prints out the information from GetFPCHeapStatus every five minutes. What I notice is that CurrHeapUsed is not growing at all, it stays pretty much the same over hours of running. However, CurrHeapSize is pretty much continuously growing. For example (cu is current heap used, cs is current heap size, cf is current heap free, mu is max heap used, ms is max heap size): heap status: cu=1,407,664, cs=34,930,688, cf=33,523,024, mu=33,621,024, ms=35,749,888 heap status: cu=1,411,264, cs=66,715,648, cf=65,304,384, mu=33,635,232, ms=67,239,936 heap status: cu=1,409,296, cs=98,435,072, cf=97,025,776, mu=33,635,232, ms=98,467,840 heap status: cu=1,411,952, cs=161,873,920, cf=160,461,968, mu=33,674,176, ms=161,873,920 heap status: cu=1,409,056, cs=193,593,344, cf=192,184,288, mu=33,674,176, ms=193,593,344 heap status: cu=1,409,360, cs=193,593,344, cf=192,183,984, mu=33,674,176, ms=193,626,112 heap status: cu=1,409,552, cs=225,312,768, cf=223,903,216, mu=33,674,176, ms=225,345,536 heap status: cu=1,408,704, cs=257,032,192, cf=255,623,488, mu=33,674,176, ms=257,064,960 etc. top shows: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 15196 root 19 0 2323m 1.8g 2780 S0 24.6 0:00.68 4 processname free -m shows: total used free sharedbuffers cached Mem: 7611 7356254 0 66 5023 -/+ buffers/cache: 2266 5344 Swap: 4094 0 4094 If I were allocating memory and not deallocating it, ie., if it were a memory leak, it seems CurrHeapUsed would be growing, right? It seems I should be concerned... what's the best direction to go from here? HEAPTRC? -SG Computer over. Virus = very yes. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: heap size growing
> I had the same problem. Burkhard, Thank you very much. This sounds very similar to the problem I'm seeing. I'll try compiling the RTL how you suggested to see if it fixes my problem, and if not I'll have to do a similar thing and create my own pools for this specific structure. -SG Computer over. Virus = very yes. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] modifying system.pp's InstallSignals
I'm working on a project in Linux where I've got some special signal handling requirements. I need to modify system.pp's InstallSignals to dynamically load an .so, look up a function by name, and make some calls into that library instead of doing what it normally does. The dynlibs unit has the code I need to call SafeLoadLibrary and GetProcedureAddress, but my problem is that obviously I can't just put "uses dynlibs" in system since, well, it's system, and there would be circular dependencies since system is pretty much first on the dependency list. My thought is that basically I'll just have to pull the code from dynlibs.pas, dynlibs.inc, and dl.pp into my own .inc file and include it rather than trying to have anything in a uses section. I'm aware that doing this will decrease the portability of my code and make me dependent on libc, but these changes I'm making to the rtl are for a very specific purpose, and I won't be using them to compile anything else. :) Does that seem like the right way for me to get the functionality of those calls available to me in InstallSignals? Or is there something easier I'm missing? Thanks, SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: modifying system.pp's InstallSignals
> Marco van de Voort wrote: > > It is roughly ok. Optionally you can also -dFPC_USE_LIBC to force the system > unit to use libc instead of syscalls, and save a few kb. Note that this is > less frequently tested though. > I wasn't aware of that, and that would actually get me a lot closer to what I'm trying to do. However, it seems to not work correctly when it comes to the signal handling. I've logged a bug on it, it's issue 13450 in Mantis. For now I'll probably go ahead and modify system. Thanks everybody for your suggestions. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] semaphores?
Is there not a cross-platform semaphore API in Free Pascal? I planned on using the callbacks in TThreadManager as described in the docs (http://www.freepascal.org/docs-html/rtl/system/tthreadmanager.html), but to my dismay they aren't initialized for win32. Bug 11206, which has been marked as "won't fix", indicates that TThreadManager should not be used by user programs. So is there a "right" way to do it, or do I have to revert to using IFDEFs and the low-level system-dependent calls? -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] dcpcrypt 64-bit?
There was a thread back in January about including DCPCrypt in the FCL. One of the questions that arose was whether it ported to 64-bit platforms. I didn't see that question ever answered, but yesterday when I started compiling one of my projects which uses it on a 64-bit machine there was some crashing in the DCPCrypt code (casting pointers as longwords and whatnot). Before I attempt to do so (or seek alternatives) has anyone here successfully modified DCPCrypt to work on 64-bit? -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] (no subject)
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/dateutil.inc?view=diff&r1=12957&r2=12958
shows that a change was recently made which replaces "Trunc" with
"Round" in the *Between routines in dateutil.inc (DaysBetween,
HoursBetween, etc.).
So this program:
-
program Project1;
{$mode objfpc}{$H+}
uses
Classes,SysUtils,DateUtils;
var
val1, val2 : TDateTime;
begin
val1 := 39939.0;
val2 := 39939.796069305557;
writeln(DaysBetween(val1, val2));
end.
-
Will now print result in a "1" instead of a "0" which is what I would
have gotten before.
Now I know I can just use trunc(DaySpan(val1, val2)) to achieve the
same result, but I was just curious as to why this change was made
which so drastically changes the functionality of these calls.
Thanks,
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: daysbetween
Disregard my email about daysbetween, I just saw this:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/dateutil.inc?view=diff&r1=12958&r2=13107
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
On Wed, May 6, 2009 at 2:11 PM, Seth Grover wrote:
> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/dateutil.inc?view=diff&r1=12957&r2=12958
> shows that a change was recently made which replaces "Trunc" with
> "Round" in the *Between routines in dateutil.inc (DaysBetween,
> HoursBetween, etc.).
>
> So this program:
> -
>
> program Project1;
>
> {$mode objfpc}{$H+}
>
> uses
> Classes,SysUtils,DateUtils;
>
> var
> val1, val2 : TDateTime;
> begin
> val1 := 39939.0;
> val2 := 39939.796069305557;
> writeln(DaysBetween(val1, val2));
> end.
> -
>
> Will now print result in a "1" instead of a "0" which is what I would
> have gotten before.
>
> Now I know I can just use trunc(DaySpan(val1, val2)) to achieve the
> same result, but I was just curious as to why this change was made
> which so drastically changes the functionality of these calls.
>
> Thanks,
>
> -SG
>
> --
> This email is fiction. Any resemblance to actual events
> or persons living or dead is purely coincidental.
>
> Seth Grover
> sethdgrover[at]gmail[dot]com
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: XML pretty formatter
I don't know what your requirements are for platform/language, but
this works nicely for me:
--
#!/usr/bin/perl
use XML::Tidy;
my $xmlFile = '/path/to/filename';
my $tidy_obj = XML::Tidy->new('filename' => $xmlFile);
$tidy_obj->tidy();
$tidy_obj->write();
--
>
> Hi, I'm looking for a simple XML pretty formatter, or parser who can remove
> all superfluous characters from XML files.
>
> My application receives an XML file from an external app. containing many
> spaces and CRLFs after closing tags, this doesn't affect my parser, but I
> need to add the XML to a log file and those spaces make very difficult to
> read the logs.
>
> Thanks in advance.
>
> Leonardo M. Ramé
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TProcess with festival
Maybe I'm just dumb, but I cannot figure out why this isn't working.
I wanted to write a simple program which uses TProcess to send input
to festival (the text-to-speech engine). On the command line I can do
something simple like this:
echo hello | /usr/bin/festival --tts --pipe
and festival will say "hello". Pretty easy...
So why won't this work?
program talkie;
{$mode objfpc}{$H+}
uses
Classes, SysUtils, Process;
var
festival : TProcess;
line : string;
begin
try
festival := TProcess.Create(nil);
try
festival.Options := [poUsePipes, poStderrToOutput, poNoConsole,
poDefaultErrorMode];
festival.CommandLine := '/usr/bin/festival --pipe --tts';
line := 'hello'
festival.Execute;
festival.Input.WriteBuffer(line[1], length(line));
finally
festival.Terminate(0);
FreeAndNil(festival);
end;
except
on E : Exception do begin
writeln('Exception: ' + E.Message);
end;
end;
end.
I've googled TProcess for about 2 hours and I'm not seeing what I'm
missing. Can someone smarter than me please illuminate me?
Thanks,
Seth
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: TProcess with festival
Okay, I figured it out...
Turns out I was using festival wrong, though I'm still not sure how.
It wasn't a problem with how I was using TProcess.
If I run festival like this (not using --tts mode)
FestivalProc.CommandLine := '/usr/bin/festival --pipe';
And pass "SayText" commands like this, rather than just passing it the
text I want read:
line := '(SayText "hello")';
FestivalProc.Input.WriteBuffer(line[1], length(line));
It works fine.
Thanks for your help!
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
On Fri, May 15, 2009 at 12:48 PM, Seth Grover wrote:
> Maybe I'm just dumb, but I cannot figure out why this isn't working.
>
> I wanted to write a simple program which uses TProcess to send input
> to festival (the text-to-speech engine). On the command line I can do
> something simple like this:
> echo hello | /usr/bin/festival --tts --pipe
> and festival will say "hello". Pretty easy...
>
> So why won't this work?
>
> program talkie;
>
> {$mode objfpc}{$H+}
>
> uses
> Classes, SysUtils, Process;
>
> var
> festival : TProcess;
> line : string;
> begin
> try
> festival := TProcess.Create(nil);
> try
> festival.Options := [poUsePipes, poStderrToOutput, poNoConsole,
> poDefaultErrorMode];
> festival.CommandLine := '/usr/bin/festival --pipe --tts';
> line := 'hello'
> festival.Execute;
> festival.Input.WriteBuffer(line[1], length(line));
> finally
> festival.Terminate(0);
> FreeAndNil(festival);
> end;
> except
> on E : Exception do begin
> writeln('Exception: ' + E.Message);
> end;
> end;
> end.
>
> I've googled TProcess for about 2 hours and I'm not seeing what I'm
> missing. Can someone smarter than me please illuminate me?
>
> Thanks,
>
> Seth
>
>
> --
> This email is fiction. Any resemblance to actual events
> or persons living or dead is purely coincidental.
>
> Seth Grover
> sethdgrover[at]gmail[dot]com
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] thanks for major signal handling fix
A huge thanks to Jonas for fixing issue 12704. I'm going to grab a copy of the trunk and compile it just so I can try this out. Thank you so much! http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=13077 Is there any chance of this being merged into the 2.2.x fixes branch? Or will this first see the light of day in 2.4.0? Thanks again, SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] re: thanks for major signal handling fix
Actually, looking closer at this fix (bug 12704, fixed in rev 13077), it might not be exactly what I was expecting it to be. Maybe somebody could clear up something I've been thinking about for a while now. Imagine this scenario. I have an FPC-compiled executable (fpcprog) and two FPC-compiled shared object libraries (libfpc1.so and libfpc2.so). Each of which installs its own set of signal handlers: fpcprog does it as part of the sysutils initialization code, and the .so's do it (since rev 13077 was checked up) in "HookSignal(RTL_SIGDEFAULT)", which (I suppose?) I would call during the libraries initialization code. Given this scenario, I would like any fatal signals (SIGSEGV, SIGILL, etc.) to be handled in the correct try/except block in whatever binary it might occur. So, for example, if I get a SIGSEGV in fpcprog, I want it to be handled in the try/except block in fpcprog. If fpcprog calls a routine in libfpc1.so, which causes a SIGSEGV, I want it to be handled by the try/except block in that routine. if fpcprog calls a routine in libfpc1.so, which in turn calls a routine in libfpc2.so, which causes a SIGSEGV, I want it to be handled by the try/except block in *that* routine, etc., etc. In my wildest dreams if I had an access violation in libfpc2.so which wasn't in any try/except block, I'd even love for it to be handled by the enclosing libfpc1.so try/except block, but that's not really a requirement for me. As long as all SIGSEGVs are handled by the try/except block in whatever binary it happens to occur in, I'd be Reading the comments for bug 12704 and the notes for revision 13077, I assumed that that was what was going to happen, as I seem to recall it worked that way in Kylix. But it still doesn't seem to work that way. I have a C program (with no signal handlers) which uses my two .so's in this example. If I call HookSignal in the .so initialization code, libfpc2.so gets called first, then libfpc1.so. When libfpc1.so calls libfpc2.so and causes and access violation, it's libfpc1.so's try/except block which catches it (I assume since it's HookSignal was the most recent one called). If I put the HookSignal calls in routines rather than in the initialization code, causing libfpc1.so to call HookSignal first, then libfpc2.so, and then cause an access violation in libfpc1.so, NO signal handler catches it. Is this a pipe dream? Or can I somehow make it work the way I'm expecting it? If needed, I could provide some example projects. Thanks, SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] re: thanks for major signal handling fix
Jonas, Thank you very much for the explanation. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] a few AssignStream questions
http://community.freepascal.org:1/docs-html/rtl/unix/assignstream.html A few questions about AssignStream: 1. I can't seem to figure out a way to see if the program I ran actually executed. For example, if I pass in something bogus for the Prog parameter (some filename that doesn't even exist), I still get a PID back. It's just that the PID is in a defunct (zombie) state. I could read the status file in /proc/ for that PID, but that seems rather a waste to do with each program I execute via AssignStream. 2. Is there a way for me to get the exit code of a program executed with AssignStream? Thanks, Seth -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: a few AssignStream questions
I actually figured out the answer to both my questions, which I'll
post here in case somebody is ever searching these archives and has
the same question:
Immediately after calling AssignStream and getting the resultant PID,
you can do something like this:
// check to see if the PID has already exited
if (fpWaitPid(pid,pcint(@exitCode),WNOHANG) = pid) then begin
// a 127 exit code indicates "command not found
if (wexitstatus(exitCode) = 127) then begin
raise Exception.Create('PipelineClass.Create: Command not found in PATH');
end;
end;
Apparently the exit code "127" has a special meaning indicating that
the command was not found.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
On Mon, Jul 27, 2009 at 6:07 AM, Seth Grover wrote:
> http://community.freepascal.org:1/docs-html/rtl/unix/assignstream.html
>
> A few questions about AssignStream:
>
> 1. I can't seem to figure out a way to see if the program I ran
> actually executed. For example, if I pass in something bogus for the
> Prog parameter (some filename that doesn't even exist), I still get a
> PID back. It's just that the PID is in a defunct (zombie) state. I
> could read the status file in /proc/ for that PID, but that seems
> rather a waste to do with each program I execute via AssignStream.
>
> 2. Is there a way for me to get the exit code of a program executed
> with AssignStream?
>
> Thanks,
>
> Seth
>
> --
> This email is fiction. Any resemblance to actual events
> or persons living or dead is purely coincidental.
>
> Seth Grover
> sethdgrover[at]gmail[dot]com
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TFPCHeapStatus miscalculations in 2.3.1
I haven't logged a bug because I haven't yet figured out the steps to exactly reproduce this, but I've been seeing something strange since I've started using 2.3.1. I have a thread pool in my application which gets assigned to run a "job" by the user, does so, and then waits until it's called on again to run another job. Since 2.3.1 gives a different heap to each thread, I've added debugging code to periodically log the heap status returned by GetFPCHeapStatus. At first, everything starts out fine: 0xB0A93BB0 heap status: cu=1456, cs=786432, cf=784976, mu=30720, ms=1048576 0xB0691BB0 heap status: cu=1456, cs=786432, cf=784976, mu=14080, ms=1048576 0xAFE85BB0 heap status: cu=1456, cs=786432, cf=784976, mu=30720, ms=1048576 Notice that "current size" minus "current free" equals "current used", just like you'd expect. After running for a few hours though, look at my numbers: 0xB0287BB0 heap status: cu=4294952816, cs=786432, cf=800912, mu=4294967280, ms=5144576 0xAFA83BB0 heap status: cu=4294873136, cs=1146880, cf=1241040, mu=4294967280, ms=5603328 0xB22C1BB0 heap status: cu=4294950256, cs=950272, cf=967312, mu=4294967280, ms=5570560 0xB26CABB0 heap status: cu=4294956896, cs=983040, cf=993440, mu=4294967280, ms=5570560 0xAF681BB0 heap status: cu=4294885088, cs=917504, cf=999712, mu=4294967280, ms=5603328 0xAF27FBB0 heap status: cu=4294844176, cs=1179648, cf=1302768, mu=4294967280, ms=5603328 0xB1EADBB0 heap status: cu=4294963824, cs=950272, cf=953744, mu=4294967280, ms=5570560 0xB3EE6BB0 heap status: cu=4294956896, cs=950272, cf=960672, mu=4294967280, ms=5570560 One by one, over time, the "current free" becomes *greater* than the "current size", so the calculations are all screwy (current used is negative, etc.). Does anyone know about changes to this which could cause this problem? It's rather annoying... I know the each heap isn't really using 4.2 gigabytes, but I wish the numbers were accurate. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: TFPCHeapStatus miscalculations in 2.3.1
Actually I was able to distill it down into a smaller example:
program Project1;
{$mode objfpc}{$H+}
uses
Classes, SysUtils;
function RandomRange(const low : longint;
const high : longint) : longint;
begin
if (high < low) then
result := high + random(low - high + 1)
else
Result := low + random(high - low + 1);
end;
procedure GetStats;
var
fpcHeapStatus : TFPCHeapStatus;
begin
fpcHeapStatus := GetFPCHeapStatus();
writeln(' heap status: cu=' +
IntToStr(fpcHeapStatus.CurrHeapUsed) + ', cs=' +
IntToStr(fpcHeapStatus.CurrHeapSize) + ', cf=' +
IntToStr(fpcHeapStatus.CurrHeapFree) + ', mu=' +
IntToStr(fpcHeapStatus.MaxHeapUsed) + ', ms=' +
IntToStr(fpcHeapStatus.MaxHeapSize));
end;
var
i : integer;
a : array of byte;
begin
randomize();
for i := 0 to 1000 do begin
SetLength(a, RandomRange(1024,1024*1024*15));
end;
GetStats();
SetLength(a, 0);
GetStats();
end.
My output:
$ ./project1
heap status: cu=4277286960, cs=16154624, cf=33834960, mu=4294897312,
ms=31752192
heap status: cu=4276332896, cs=458752, cf=19093152, mu=4294897312, ms=31752192
Seems like that should never happen. I'll log an issue in the bug
tracking system.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] 2.3.1 rev 13498 breaks synapse
For anyone who cares to know: revision 13498 of 2.3.1 breaks synapse (apparently unless you have "legacysocket" defined, see http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/socketsh.inc?r1=7328&r2=13498). So if your project uses synapse and you're getting FPC from the trunk, you're going to have problems. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] cross compiling x64_64 to i386 linux
I'm trying to cross-compile on Ubuntu 9.10 x86_64 for i386. Here's what I've done so far: I got FPC from the fixes_2_4 branch in SVN and did make/make install. I used samplecfg to generate /etc/fpc/fpc.cfg. I followed the wiki (http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux) and did the steps listed there, including creating the i386-linux-ld and i386-linux-ls scripts in /usr/bin and compiling for the i386 target, so I ended up with a ppc386. At this point I could do a simple "hello world" program which would generate a 64-bit binary if i selected x86_64 for the target in lazarus under "Compiler Options | Code" and a 32-bit binary if i selected i386 as the target. So far so good. I then tried to compile something a bit more complicated (not that much more, though: I just tried to include "cthreads") and I got an error about crti.so not being found: /usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o /usr/bin/ld: cannot find /usr/lib/crti.o build.lpr(16,1) Error: Error while linking As the Wiki is extremely vague as to what to do for fpc.cfg (Sorry, but "Edit your /etc/fpc.cfg file if needed" is not very useful), I did change this line: #-Fl/lib;/usr/lib to -Fl/lib;/usr/lib;-Fl/lib32;/usr/lib32 However, to no avail. However, I did discover that /usr/lib32 doesn't even have crti.o, so a little more investigation made me realize I needed to install the "libc6-dev-i386" package, after which I did, in fact, have that file. However, I'm still unable to compile a 32-bit executable that includes "cthreads" in its uses clause. ld still complains about not being able to find crti.o, despite my having added /usr/lib32 to the -Fl line of my fpc.cfg. I do have this in my fpc.cfg: == # set binutils prefix #IFNDEF CPUI386 #IFNDEF CPUAMD64 #DEFINE NEEDCROSSBINUTILS #ENDIF #ENDIF #IFNDEF linux #DEFINE NEEDCROSSBINUTILS #ENDIF #IFDEF FPC_CROSSCOMPILING #IFDEF NEEDCROSSBINUTILS -XP$fpctarget- #ENDIF NEEDCROSSBINUTILS #ENDIF == but I don't know if that's correct or whatever, that's just what samplecfg generated. Observe: compiling for 64-bit == $ /usr/local/bin/fpc -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. -obuild build.lpr Hint: Start of reading config file /etc/fpc.cfg Hint: End of reading config file /etc/fpc.cfg Free Pascal Compiler version 2.3.1 [2009/11/02] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for x86-64 Compiling build.lpr Linking build ld here i am ld.real: warning: link.res contains output sections; did you forget -T? 17 lines compiled, 0.2 sec 2 hint(s) issued == attempting to compile for 32-bit == $ /usr/local/bin/fpc -Pi386 -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. -obuild build.lpr Hint: Start of reading config file /etc/fpc.cfg Hint: End of reading config file /etc/fpc.cfg Free Pascal Compiler version 2.3.1 [2009/11/02] for i386 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for i386 Compiling build.lpr Linking build ld: warning: link.res contains output sections; did you forget -T? ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o ld: cannot find /usr/lib/crti.o build.lpr(16,1) Error: Error while linking build.lpr(16,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled) == I sort of think that /usr/bin/i386-linux-ld isn't being called. I added an "echo here I am" sort of line to that bash script, and I never see that echo happen. I'm sure there's some magic I need to do in my fpc.cfg file, but I'm having a hard time finding specifically what it is. I'd really like to be able to compile for x86_64 and i386 in the same development environment simply by selecting a different target from the Lazarus UI and have it "just work." If anyone can offer assistance, I'd surely appreciate it. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: cross compiling x64_64 to i386 linux
Okay, in further investigation I am now manually forcing fpc to use i386-linux-ld for linking by using the "-Pi386 -XPi386-linux-" compiler flags (-P for the target and -XP for the binutils prefix). I assume there's something wrong in my fpc.cfg or it would do this manually, but I don't know what it is. Still, at least I'm getting i386-linux-ld to be called. However, ld is still not searching /usr/lib32. I also tried manually adding -Fl/usr/lib32 to the fpc command line but that didn't help. So apparently I have to somehow tell ld to look there... -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com On Mon, Nov 2, 2009 at 12:45 PM, Seth Grover wrote: > I'm trying to cross-compile on Ubuntu 9.10 x86_64 for i386. Here's > what I've done so far: > > I got FPC from the fixes_2_4 branch in SVN and did make/make install. > > I used samplecfg to generate /etc/fpc/fpc.cfg. > > I followed the wiki > (http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux) and did > the steps listed there, including creating the i386-linux-ld and > i386-linux-ls scripts in /usr/bin and compiling for the i386 target, > so I ended up with a ppc386. > > At this point I could do a simple "hello world" program which would > generate a 64-bit binary if i selected x86_64 for the target in > lazarus under "Compiler Options | Code" and a 32-bit binary if i > selected i386 as the target. So far so good. > > I then tried to compile something a bit more complicated (not that > much more, though: I just tried to include "cthreads") and I got an > error about crti.so not being found: > > /usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for > /usr/lib/crti.o > /usr/bin/ld: cannot find /usr/lib/crti.o > build.lpr(16,1) Error: Error while linking > > As the Wiki is extremely vague as to what to do for fpc.cfg (Sorry, > but "Edit your /etc/fpc.cfg file if needed" is not very useful), I did > change this line: > > #-Fl/lib;/usr/lib > > to > > -Fl/lib;/usr/lib;-Fl/lib32;/usr/lib32 > > However, to no avail. However, I did discover that /usr/lib32 doesn't > even have crti.o, so a little more investigation made me realize I > needed to install the "libc6-dev-i386" package, after which I did, in > fact, have that file. > > However, I'm still unable to compile a 32-bit executable that includes > "cthreads" in its uses clause. ld still complains about not being able > to find crti.o, despite my having added /usr/lib32 to the -Fl line of > my fpc.cfg. > > I do have this in my fpc.cfg: > == > # set binutils prefix > > #IFNDEF CPUI386 > #IFNDEF CPUAMD64 > #DEFINE NEEDCROSSBINUTILS > #ENDIF > #ENDIF > > > #IFNDEF linux > #DEFINE NEEDCROSSBINUTILS > #ENDIF > > > #IFDEF FPC_CROSSCOMPILING > #IFDEF NEEDCROSSBINUTILS > -XP$fpctarget- > #ENDIF NEEDCROSSBINUTILS > #ENDIF > == > > but I don't know if that's correct or whatever, that's just what > samplecfg generated. > > Observe: > compiling for 64-bit > == > $ /usr/local/bin/fpc -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. -obuild build.lpr > Hint: Start of reading config file /etc/fpc.cfg > Hint: End of reading config file /etc/fpc.cfg > Free Pascal Compiler version 2.3.1 [2009/11/02] for x86_64 > Copyright (c) 1993-2009 by Florian Klaempfl > Target OS: Linux for x86-64 > Compiling build.lpr > Linking build > ld here i am > ld.real: warning: link.res contains output sections; did you forget -T? > 17 lines compiled, 0.2 sec > 2 hint(s) issued > == > > attempting to compile for 32-bit > == > $ /usr/local/bin/fpc -Pi386 -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. > -obuild build.lpr > Hint: Start of reading config file /etc/fpc.cfg > Hint: End of reading config file /etc/fpc.cfg > Free Pascal Compiler version 2.3.1 [2009/11/02] for i386 > Copyright (c) 1993-2009 by Florian Klaempfl > Target OS: Linux for i386 > Compiling build.lpr > Linking build > ld: warning: link.res contains output sections; did you forget -T? > ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o > ld: cannot find /usr/lib/crti.o > build.lpr(16,1) Error: Error while linking > build.lpr(16,1) Fatal: There were 1 errors compiling module, stopping > Fatal: Compilation aborted > Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you > did not specify a source file to be compiled) > ===
[fpc-pascal] Re: cross compiling x64_64 to i386 linux
> You might have to tell it simply NOT to look in /usr/lib > > E.g. like described in paragraph 3.4.1 of the buildfaq: > > http://www.stack.nl/~marcov/buildfaq.pdf > Thank you! That seemed to get me past the rest of my errors. The final working command was: /usr/local/bin/fpc -Xd -Pi386 -XPi386-linux- -MObjFPC -Scgi -XX -vewnhi -l -Fu. -oproject1 project1.lpr The one other thing I had to do was change one of the lines in fpc.cfg so that it would look in "/usr/lib/gcc/x86_64-linux-gnu/32/4.4.1" rather than "/usr/lib/gcc/x86_64-linux-gnu/4.4.1". So basically I ended up with: == #ifdef cpui386 -Fl/usr/lib/gcc/x86_64-linux-gnu/32/4.4.1 -Fl/lib32 -Fl/usr/lib32 #endif == I haven't tried to build anything too complicated, but most simple compilations seem to be working. Thanks again! -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Inconsistency detected by ld.so
Using the examples from the test suite for an .so and a host program (http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw12704a.pp?view=markup and http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw12704b.pp?view=markup), when I run the host program I get: $ ./tw12704b Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! It seems this is a fairly recent development, but I'm at a loss as to what causes it. My setup is just a generic Ubuntu 9.10 32-bit installation (uname -a reports: Linux tlacuache-laptop 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 GNU/Linux). FPC 2.4.0 from http://svn.freepascal.org/svn/fpc/tags/release_2_4_0 (revision 14294). Any ideas? Should I file a bug report? -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Inconsistency detected by ld.so
Interestingly: $ ldd tw12704b linux-gate.so.1 => (0x00c69000) libtw12704a.so => ./libtw12704a.so (0x00701000) However, if I add a unit that uses glibc (like the systemlog unit) I get: $ ldd tw12704b linux-gate.so.1 => (0x00df6000) libtw12704a.so => ./libtw12704a.so (0x0080a000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00c27000) /lib/ld-linux.so.2 (0x002c7000) And I don't get the error when the program runs. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Inconsistency detected by ld.so
> > Well, not that recent: > http://www.hu.freepascal.org/lists/fpc-pascal/2008-April/017199.html > Wow, how embarrassing. Not only is there already a mailing list thread on the topic, but it was started by me. I have a really bad memory. > > It seemed to be specific to a particular machine of yours. > At the moment, however, I am duplicating this on a number of different ubuntu installations, (admittedly, all Ubuntu 9.10 installations) and so is my coworker on his machine. In fact, last night I set up a brand new fresh virtual machine into which I installed Ubuntu 9.10 and the bare minimum of packages to grab FPC from svn and compile it, and I was able to reproduce it. Does anyone else see this? -SG ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Inconsistency detected by ld.so
So I've been testing the problem with the "Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 || i == nloaded' failed!" error with tests tw12704a and tw12704b on various different platforms. So far it's reproduced on every 32-bit Ubuntu installation I've tried (about half a dozen 9.04 and 9.10 installations I have around) and it also failed on a custom RedHat-based distribution we use internally in our company. However, it does not reproduce on my CentOS 5.3 installation, nor does it reproduce on my 64-bit Ubuntu 9.10 installation. Is there someone with more knowledge of how linking and ld.so works in Linux that has any ideas? I really don't think it's just something I'm doing wrong, because I can reproduce it on several different platforms, including stock virtual machines I haven't had a chance to mess up yet. :) Even if any of you are FPC users running Ubuntu could you give this a try and see if you can reproduce it? -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Inconsistency detected by ld.so
http://bugs.freepascal.org/bug_view_advanced_page.php?bug_id=15278 I have logged a bug for this. I can't see how it's anything I'm doing personally wrong (see my "Steps to Reproduce" in the bug report). -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] different windows/linux behavior with enumerated types and write/writeln
If I have a program like this:
--
program Project1;
{$mode objfpc}{$H+}
type
whatever = (seth, paul, ken);
var
haha : whatever;
begin
haha := seth;
writeln(haha);
end.
--
I can compile it in linux with FPC and run it and get the following output:
--
$ ./project1
seth
--
In other words, it actually prints out the name of the enumerated value.
In windows the program does not compile with an error of "Error: Can't
read or write variables of this type".
Why the difference in behavior?
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: different windows/linux behavior with enumerated types and write/writeln
> Different compiler version. The above is only possible as of 2.4.0. I'm sorry, I should have realized my Windows environment wasn't as up-to-date as my Linux environment. You're absolutely right. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] values for ThreadSetPriority
After reading the online docs, and searching this list, I'm still confused. Hopefully someone can straighten me out. http://www.hu.freepascal.org/docs-html/rtl/system/threadsetpriority.html says that it takes for a priority values from -15 to 15. The comment to the right of the declaration says that "0" is normal. Are these numbers like nice's, where negative numbers are more favorable (higher priority) and positive numbers are less favorable (lower priority)? Also, to further confuse my mind, I found this: http://community.freepascal.org:1/docs-html/rtl/classes/tthreadpriority.html which has some enumerations. How do those come into play? Are those just for TThread descendents? I'm just trying to find the correct cross-platform approach for changing thread priority of threads started with BeginThread. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Which regex unit to use?
> Hi, > > There are a few regex units include with FPC and Lazarus, and dozens more > available for Delphi (and probably FPC too). > > Which one is the most well known, or best to use, or most feature complete > regarding syntax etc...? > > * /packages/regexpr/src/old/regexpr.pp > * /packages/regexpr/src/regexp.pp > * /components/synedit/synregexpr.pas > * TRegExpr (no idea what is latest and if FPC compatible) > * ? > > > I guess I'm looking for something similar or compatible with PCRE syntax, > but in native Object Pascal, so it can be compiled into my applications. > > > Regards, > - Graeme - I have had good luck with TRegExpr and have been using it in FPC for a long time. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] gdb, dwarf, and ansistring
Given the following example:
program project1;
{$mode objfpc}{$H+}
procedure doit (var s : ansistring);
begin
s := s + ' ' + s;
end;
var
s : ansistring;
begin
s := 'test';
doit(s);
end.
When I compile for x86_64 with "fpc -Px86_64 -g -gl -gw project1.lpr",
and set a breakpoint in "doit" in GDB, I see the following:
(gdb) whatis S
type = &ANSISTRING
(gdb) print S
$12 = (&ANSISTRING) @0x627130
(gdb) whatis S^
type = ANSISTRING
(gdb) print S^
$13 = 116 't'
(gdb) x/s S
0x74:
(gdb) x/s S^
0x74:
When I compile with "fpc -Px86_64 -g -gl project1.lpr", I get the same
result. When I compile for i386 with "fpc -Pi386 -g -gl -gw
project1.lpr", I have the same issue. However, when I compile for i386
with "fpc -Pi386 -g -gl project1.lpr", I get:
(gdb) whatis S
type = ANSISTRING
(gdb) print S
$1 = (ANSISTRING) 0x8064074 "test"
(gdb) x/s S
0x8064074 <_$PROJECT1$_Ld3>: "test"
How can I print the value of a var ansistring parameter in gdb with
dwarf debugging information compiled in?
I am compiling with FPC 2.4.0 (built from svn from the 2.4.0 release
tag) on Ubuntu 9.10 x86_64.
Thanks,
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: gdb, dwarf, and ansistring
> I believe this is a bug that was introduced with GDB 7.0
> Jonas
You're right, I tried it with gdb 6.8 and it worked as you described:
(gdb) print S
$1 = (&ANSISTRING) @0x8069410: 0x8065074 'test'
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
On Wed, Mar 3, 2010 at 8:02 AM, Seth Grover wrote:
> Given the following example:
>
>
> program project1;
>
> {$mode objfpc}{$H+}
>
> procedure doit (var s : ansistring);
> begin
> s := s + ' ' + s;
> end;
>
> var
> s : ansistring;
> begin
> s := 'test';
> doit(s);
> end.
>
>
> When I compile for x86_64 with "fpc -Px86_64 -g -gl -gw project1.lpr",
> and set a breakpoint in "doit" in GDB, I see the following:
>
> (gdb) whatis S
> type = &ANSISTRING
> (gdb) print S
> $12 = (&ANSISTRING) @0x627130
> (gdb) whatis S^
> type = ANSISTRING
> (gdb) print S^
> $13 = 116 't'
> (gdb) x/s S
> 0x74:
> (gdb) x/s S^
> 0x74:
>
> When I compile with "fpc -Px86_64 -g -gl project1.lpr", I get the same
> result. When I compile for i386 with "fpc -Pi386 -g -gl -gw
> project1.lpr", I have the same issue. However, when I compile for i386
> with "fpc -Pi386 -g -gl project1.lpr", I get:
>
> (gdb) whatis S
> type = ANSISTRING
> (gdb) print S
> $1 = (ANSISTRING) 0x8064074 "test"
> (gdb) x/s S
> 0x8064074 <_$PROJECT1$_Ld3>: "test"
>
> How can I print the value of a var ansistring parameter in gdb with
> dwarf debugging information compiled in?
>
> I am compiling with FPC 2.4.0 (built from svn from the 2.4.0 release
> tag) on Ubuntu 9.10 x86_64.
>
> Thanks,
>
> -SG
>
>
> --
> This email is fiction. Any resemblance to actual events
> or persons living or dead is purely coincidental.
>
> Seth Grover
> sethdgrover[at]gmail[dot]com
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: gdb, dwarf, and ansistring
> I believe this is a bug that was introduced with GDB 7.0 ... > I don't know whether anyone already reported this bug to the GDB developers. http://sourceware.org/bugzilla/show_bug.cgi?id=11349 I just reported it as a bug to GDB. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: gdb, dwarf, and ansistring
Thanks, I have done as you suggested and attached a compiled version of the program, the output of readelf -gw, and the assembly generated by "fpc -a -al -an" as well. Hopefully this will allow the GDB developers to more easily figure out the problem. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] implicitly linking FPC-generated .dll from Visual Studio
First, let me declare my ignorance of MS development and Visual Studio in general. I've got a FPC-generated .dll file I want to implicitly link with in a Visual Studio (Visual C++) project. If I understand what I'm reading, I have to have a "import library" .lib file which corresponds to my .dll. I don't see an obvious way to create this file using FPC directly. Can anyone with experience using FPC-generated .dll's in VS help me out? So far my googling has turned up some MS tools (dumpbin.exe and imp.exe) which I can use to generate a .lib file from a .dll file (although in kind of a roundabout way), and I've also come up with ImpLib (http://implib.sourceforge.net) which has some tools (dll2def and fasm) which will generate a .def file and then a .lib file. Do I have to turn to third party tools to do this, or is there an easier way to generate what I need with FPC? What about the next step (actually using the .dll in Visual Studio)? I realize this message is more about VS than FPC, so I apologize if it's offtopic. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] stdcall vs. cdecl: another "using a FPC-generated .dll with Microsoft Visual C++" question
I appreciated Henry's comment regarding my last question (generating a
.lib file from a FPC-generated for linking with VC++). I ended up
using implib (http://implib.sourceforge.net) to generate the .def file
with dll2def.exe and then fasm.exe to create the .lib file from that,
and VC++ seems to link fine against it.
My fight is with calling conventions and exported names. I've read the
programmers guide chapters 6, 7, and 12, and got a lot of useful
information out if it. I'm trying now to get a grasp of how different
calling conventions work, what different compilers generate what name
decorations with the different calling conventions, what compilers
require when linking against them, etc.
I've got a little test library with two functions:
function stdcallSquare(value : cint) : cint; stdcall;
function cdeclSquare(value : cint) : cint; cdecl;
And I'm trying to use them in a Visual C++ project. In my .cpp file, I have:
extern "C" {
int __declspec(dllimport) __cdecl cdeclSquare(int value);
int __declspec(dllimport) __stdcall stdcallSquare(int value);
}
In the "exports" section of my FPC library, I can simply export
cdeclSquare without modifying the name it's exported as, and VC++
finds and links against and calls it just great.
If I try to export sdtcallSquare without modifying the name it's
exported as, VC++ complains with "1>testdll.obj : error LNK2019:
unresolved external symbol __imp__stdcallsqu...@4 referenced in
function _wmain".
If I put "stdcallSquare name 'stdcallsqu...@4'" in my exports section,
then VC++ seems to be happy with it and it links and calls the routine
Ok.
So my question is, is there a way to have FPC automatically generate
the decoration VC++ is looking for? Or does anyone know of a way to
make VC++ find and link stdcall functions without the decorations?
I know I could just use cdecl and forget about stdcall altogether, but
I'd like to learn how to do it with stdcall but I'm just curious to
see if there's a way to get stdcall to work without having to manually
put the decorations on the exported names myself.
Thanks,
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: stdcall vs. cdecl: another "using a FPC-generated .dll with Microsoft Visual C++" question
> Not exactly on topic, but I'm curious why you want to link statically > like this and not dynamically. AFAIK, VS can call LoadLibrary and > GetProcAddress just fine. > > Jeff. You're right, it can. The product the company I work for produces is a shared library, and I'm just looking into and making sure that our .dll is usable in as many was by as many platforms as possible. If a customer wants to link statically, I'd like to be able to have that option. FWIW, I've just gone through and updated our .pas/.h headers to interface with our .so/.dll to use cdecl in both UNIX and Windows and it seems to work fine. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] compilation verbosity
fpc doesn't seem to respect the -v,X> flags for me. I'm compiling a shared object library (on an Ubuntu Linux 64-bit platform cross-compiling to 32-bit) and I've tried -ve, -vew, -v0, but I still get hints. Anyone else experience this? -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: compilation verbosity
Sorry, not sure what happened on the first line of that email, I meant the -v flag described in the fpc help as " -v Be verbose. is a combination of the following letters:.." -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com On Wed, Apr 14, 2010 at 4:17 PM, Seth Grover wrote: > fpc doesn't seem to respect the -v,X> flags for me. > > I'm compiling a shared object library (on an Ubuntu Linux 64-bit > platform cross-compiling to 32-bit) and I've tried -ve, -vew, -v0, but > I still get hints. > > Anyone else experience this? > > -SG > > -- > This email is fiction. Any resemblance to actual events > or persons living or dead is purely coincidental. > > Seth Grover > sethdgrover[at]gmail[dot]com > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: compilation verbosity
> Maybe the source code contains {$hints on}
> Jonas
Ah, why didn't I think of that. I had a function and I was doing something like:
{$HINTS OFF}
my function here
{$HINTS ON}
but in my mind for some reason I was thinking this would mean "turn
hints back on only if they were on before." Of course that's not
right.
Thanks, it's working great now.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] annoying gdb bug fixed
For those of you interested, in the GDB 7.1 release there is a bug which prevents "var" arguments from being "print"ed correctly in GDB. I logged a bug for this (http://sourceware.org/bugzilla/show_bug.cgi?id=11349), for which a GDB developer checked up a fix into the GDB cvs trunk late last week. I've tested it and the patches they provided do fix the problem. So, if you feel inclined to compile GDB from scratch this will solve a very annoying problem debugging FPC-compiled binaries with GDB. Good luck, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: annoying gdb bug fixed
> This was me... > Pierre Muller Pierre, thanks so much for taking the time to look at and resolve this bug. It's working beautifully now. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] problem linking when using "cthreads" when cross-compiling for arm
After doing some research (mostly reading http://wiki.lazarus.freepascal.org/Setup_Cross_Compile_For_ARM) and experimenting, I am now cross compiling for ARM Linux from inside an x86 Linux VM. I followed the instructions in the aforementioned link with a few minor adjustments for my environment, and it's working quite nicely. I am able to compile FPC programs which use various RTL units and everything seems to compile fine and then rune fine when copied over to my Nokia N800. The way I set it up was to create a "/usr/local/bin/arm" directory, with symlinks in that directory like this: $ ls -l total 0 lrwxrwxrwx 1 root root 15 2010-05-24 08:53 ar -> ../arm-linux-ar lrwxrwxrwx 1 root root 15 2010-05-24 08:53 as -> ../arm-linux-as lrwxrwxrwx 1 root root 15 2010-05-24 08:53 ld -> ../arm-linux-ld which point to the arm-linux-* binaries that were installed when I compiled and installed binutils for arm. I also have a /usr/local/lib/arm directory containing the contents of my /lib and /usr/lib directories which I copied over from my N800. Then, in fpc.cfg I have: #ifdef cpuarm -Xd -XP/usr/local/bin/arm/ -Fl/usr/local/lib/arm/ #endif so that the regular library paths aren't used (-Xd), the binutils from /usr/local/bin/arm/ are used (-XP) and the libraries in /usr/local/lib/arm/ are found (-Fl). This all seems to work fine. FWIW, the command I used to do the crossinstall was: sudo make crossinstall CPU_TARGET=arm OS_TARGET=linux CROSSBINDIR=/usr/local/bin/arm/ OPT=-dFPC_ARMEL INSTALL_PREFIX=/usr/local When I compile simple test programs everything is found Ok, even when using a unit like systemlog which causes libc to be linked. However, when I try to compile something that uses cthreads, I get the following errors: $ fpc -Parm runthreads.pas Free Pascal Compiler version 2.4.1 [2010/05/24] for arm Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for ARMEL Compiling runthreads.pas runthreads.pas(25,10) Warning: Local variable "s" does not seem to be initialized Assembling runthreads Linking runthreads /usr/local/bin/arm/ld: warning: link.res contains output sections; did you forget -T? /usr/local/lib/fpc/2.4.1/units/arm-linux/rtl/cthreads.o: In function `CTHREADS_LOADPTHREADS$$BOOLEAN': cthreads.pp:(.text.n_cthreads_loadpthreads$$boolean+0xc): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/arm//libdl.a(dlopen.o): In function `dlopen': (.text+0xc): undefined reference to `__dlopen' /usr/local/lib/arm//libdl.a(dlclose.o): In function `dlclose': (.text+0x0): undefined reference to `__dlclose' /usr/local/lib/arm//libdl.a(dlsym.o): In function `dlsym': (.text+0xc): undefined reference to `__dlsym' /usr/local/lib/arm//libdl.a(dladdr.o): In function `dladdr': (.text+0x0): undefined reference to `__dladdr' runthreads.pas(28,45) Error: Error while linking runthreads.pas(28,45) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/local/bin/ppcarm returned an error exitcode (normal if you did not specify a source file to be compiled) Here's what I have pthread-related in my /usr/local/lib/arm directory: $ ll libpthread* -rw-r--r-- 1 root root 77k 2010-05-24 10:27 libpthread-2.5.so -rw-r--r-- 1 root root 268k 2010-05-24 10:27 libpthread.a -rw-r--r-- 1 root root 1.3k 2010-05-24 10:27 libpthread_nonshared.a -rw-r--r-- 1 root root 245 2010-05-24 10:40 libpthread.so lrwxrwxrwx 1 root root 17 2010-05-24 10:40 libpthread.so.0 -> libpthread-2.5.so $ cat libpthread.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-littlearm) GROUP ( /usr/local/lib/arm/libpthread.so.0 /usr/local/lib/arm/libpthread_nonshared.a ) Does anyone have any suggestions? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: problem linking when using "cthreads" when cross-compiling for arm
Marco said: > > (btw: > -XP should be followed by the prefix, not the path. IOW if you do > -XParm-linux- then you wouldn't need those symlinks. > > The makefile name of this is BINUTILSPREFIX > ) Thank you, I have adjusted my setup accordingly. > > The problem is that libdl misses functions that it should have. A list of > symbols link libdl.a (nm -a ) might help. > > I suspect the target simply doesn't support dynloading of libraries. Thank you for pointing me in the right direction! I have found the solution. Originally, on my device I had installed the "libc6-dev" package because it contained various object files (crti.o, for example) that FPC needed to link. After I copied the contents of /usr/lib and /lib to my cross-compile build VM, I removed the package from my device to conserve disk space. The file "libdl.a" was included in this libc6-dev package, so I had copied it over to my build vm. However, on a whim I moved the file into the trash and tried compiling again. The compiler complained about not being able to find libdl, so I put a symlink for libdl.so.2 as libdl.so and then it compiled fine, and ran correctly as well once I copied it to the target device. So apparently having that libdl.a around was confusing things. Thanks again for your help. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] access violation somehow related to dlopen'ing libssl
0x 4294967295 r9 0x0 0 r100x7fffdb00 140737488345856 r110x76f5f360 140737336701792 r120x0 0 r130x7fffdd10 140737488346384 r140xf7fd5000 -134393856 r150xf9908c1f 4186999839 rip0x77de66d5 0x77de66d5 eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) info shared >FromTo Syms Read Shared Object Library 0x77ddcaf0 0x77df5814 Yes (*) /lib64/ld-linux-x86-64.so.2 0x77bbc2b0 0x77bd3ad8 Yes (*) /usr/lib/libssh2.so.1 0x779b3de0 0x779b49c8 Yes (*) /lib/libdl.so.2 0x77776c10 0x777a25b8 Yes (*) /lib/libssl.so.0.9.8 0x7743d040 0x774f82e8 Yes (*) /lib/libcrypto.so.0.9.8 0x771be260 0x771cad38 Yes (*) /lib/libz.so.1 0x76e588c0 0x76f69f5c Yes (*) /lib/libc.so.6 (*): Shared library is missing debugging information. The odd thing is, if I compile this program for i386, it runs fine. In that case: $ ldd ./syna64test linux-gate.so.1 => (0xf77d8000) libssh2.so.1 => /usr/lib32/libssh2.so.1 (0xf778f000) libdl.so.2 => /lib32/libdl.so.2 (0xf778a000) libgcrypt.so.11 => /lib32/libgcrypt.so.11 (0xf7717000) libz.so.1 => /usr/lib32/libz.so.1 (0xf7702000) libc.so.6 => /lib32/libc.so.6 (0xf75a8000) /lib/ld-linux.so.2 (0xf77d9000) libgpg-error.so.0 => /lib32/libgpg-error.so.0 (0xf75a3000) $ ./syna64test $ So, for some reason, when building for x86_64, the combination of my program linking against a .so which has a libssl dependency, combined with synapse's ssl_openssl_lib attempting to dlopen and then call GetProcedureAddress for a procedure in libssl causes things to blow up. Any suggestions? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: access violation somehow related to dlopen'ing libssl
Whoa... I discovered that simply adding "dynlibs" to the interface uses clause of ssl_openssl_lib causes the crash to go away and everything to work fine. After further experimentation, if I put "dynlibs" in the uses clause of ssl_openssl_lib prior to "Classes", it still crashes. If I add it after "Classes", the crash goes away. Not sure what that means... -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: access violation somehow related to dlopen'ing libssl
Michael wrote: > If 'sysutils' is somewhere included (I assume it is) it means that a > different loadlibrary function is called. Thanks for the response. Actually, I saved the assembly code generated from both ways and compared them and realized the problem was with the definition of HModule. classesh.inc has: HMODULE = longint; and dynlibs.pas has: HModule = TLibHandle; If the classes one gets used, it crashes. Anyway, I know what to do now. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] question about FPC heap and threading
These are very simple questions, but I just want to make sure a few of my assumptions are correct: 1. The default FPC heap manager uses one heap per thread, right? I am basing this assumption off of things I have read in various threads on this and other mailing lists since around 2.2.x-ish. Looking at heap.inc I see that the "freelists" variable is a threadvar, which indicates to me that each thread has its own heap. 2. When a thread is started via, for example, BeginThread (http://www.freepascal.org/docs-html/rtl/system/beginthread.html) this heap, as well as all other threadvars in my code and the rtl code, is setup and initialized automatically, correct? 3. When this thread exits (in the example of using BeginThread, when the TThreadFunc function passed in to BeginThread terminates) the heap for that thread, in addition to the other threadvars, are automatically disposed, correct? The reason I ask is that I have a program (which executes a lot of worker threads via BeginThread) which is experiencing increasing memory usage. heaptrc does not indicate that there are any leaks, but it's a fairly complex program (we have some units where we're getting memory from libc directly, don't ask) so I'm not even supposing at this point that the increasing memory belongs to the FPC heaps at all, but I'm just trying to make sure I understand everything that's going on before I go making assumptions about where the memory allocation is coming from. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] a few more heap questions
A while ago I asked a question on this list: >> 3. When this thread exits (in the example of using BeginThread, when >> the TThreadFunc function passed in to BeginThread terminates) the heap >> for that thread, in addition to the other threadvars, are >> automatically disposed, correct? To which Jonas replied, helpfully: > Only the already freed blocks that are still around are automatically > disposed, because allocated blocks > may still be referenced by other threads. The memory reserved for holding > threadvars is indeed freed. I need to understand a few more things... I'm still a little confused at how this works. I've read heap.inc and cthreads.pp but I'm still a little fuzzy on a few details... In heap.inc, the "freelists" variable which represents the heap, is a threadvar. So when GetMem is called, it works its way down into SysGetMem_Fixed and uses the heap for that thread to get the memory. This makes sense to me. What I'm still a little unsure on is what happens to the heap when the thread exits. If the heap itself (freelists) is a threadvar, how is the statement "Only the already freed blocks that are still around are automatically disposed, because allocated blocks may still be referenced by other threads" accomplished? Are any still-allocated blocks belonging to that heap relocated to be managed by some other heap so that they can be used and/or tracked (by heaptrc, for example)? I think my reading of FinalizeHeap in heap.inc, called by DoneThread in thread.inc indicates this. So in other words, here's what I *think* is happening, please tell me if I'm correct: - when a thread is started, InitHeapThread in heap.inc is called by InitThread in thread.inc, which initializes that thread's freelists record - the thread runs, all GetMem/FreeMem calls in that thread use that thread's heap - when the thread exists, FinalizeHeap in heap.inc is called by DoneThread in thread.inc. If there are any chunks still allocated on that heap then those blocks are reassigned to the orphaned_freelists heap (which is global across all threads) so that that memory can still be used by other threads and so that something like heaptrc would still work to catch those blocks. - then, once any remaining blocks of freelists are no longer managed by freelists, ReleaseThreadVars is called to actually free the memory associated with the threadvar itself Is that correct? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] CRelocateThreadVar called from fpc_pushexceptaddr/fpc_popaddrstack
The documentation (http://www.freepascal.org/docs-html/prog/progse46.html) indicates that "RelocateThreadVar is called each time when a thread is started, and once for the main thread." Is it not called much more frequently than this? I was doing some profiling with valgrind and noticed that every call to fpc_pushexceptaddr/fpc_popaddrstack resulted in a call to CRelocateThreadVar. From stepping through in gdb, it appears that *every* time a threadvar is accessed (in this case, the exception stack). It doesn't run through all of the code of CRelocateThreadVar because of the non-nill result of pthread_getspecific, but it is called. It seems that every time a threadvar is accessed, we're checking to make sure threadvars have been initialized/allocated for this particular thread. Is that correct? If not, can someone explain the reasoning behind this to me? I can certainly see why exceptions are to be avoided in performance-critical code. :). Thanks, Seth -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: CRelocateThreadVar called from fpc_pushexceptaddr/fpc_popaddrstack
Thanks, Jonas. As always your answers are very helpful. Cheers, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] HookSignal, "halt", and unhandled exceptions
Greetings! An interesting problem I've run into: Under Linux, I have a small example program written in C (we'll call it cprog) which uses a FPC-compiled shared object library (libfpcso1.so) inside which I want to catch access violations in try/except blocks. I don't care about access violations in the C program, and by "don't care" I mean "don't care if it halts the program." Thanks to HookSignal(RTL_SIGDEFAULT) (see http://www.freepascal.org/docs-html/rtl/sysutils/hooksignal.html) once the .so installs its signal handler, catching the exceptions in the try/except blocks works beautifully. However, if a segfault is raised in cprog, strange behavior happens. The FPC signal handler catches the signal, and goes into the "handle unhandled exception" code, which is what I wou ld expect. It raises a runtime error 217, which is what I would expect. However, it does not halt the program. What actually happens is it gets into an infinite loop of raising runtime error 217. Here's the output. Note that the first 3 lines of output are me testing that the exceptions are handled correctly in the try/except block in the .so, which they are. Then my c program causes a segfault, after which I get the infinity r.e. 217 output: === $ ./cprog handled inside so 2: Access violation handled inside so 2: Division by zero called libc, handled inside so 2: Access violation An unhandled exception occurred at $08048534 : EAccessViolation : Access violation $08048534 line 50 of cprog.c Runtime error 217 at $F7761740 $F7761740 $F77617B4 $F7783DA5 $F77647FE $F75D1BD6 $08048431 Runtime error 217 at $F7761740 $F7761740 $F77617B4 $F7783DA5 $F77647FE $F75D1BD6 $08048431 An unhandled exception occurred at $F77617EF : EAccessViolation : $F77617EF $F7783DA5 $F77647FE Runtime error 217 at $F7761740 $F7761740 Runtime error 217 at $F7761740 $F7761740 Runtime error 217 at $F7761740 $F7761740 Runtime error 217 at $F7761740 $F7761740 An unhandled exception occurred at $F77617EF : EAccessViolation : $F77617EF $F7783DA5 $F77647FE $F7783DA5 $F77647FE Runtime error 217 at $F7761740 ... (at this point it continues like this forever) === It seems the cause of this is that halt, which calls InternalExit and System_exit, which in turn calls haltproc, does not actually halt the program in the case of a library. Instead, haltproc for the library just calls InternalExit again and returns. I took my test case to an even simpler one, and simple removed the try/except block around the access violation in my test .so. So now, all my test C program is call libfpcso1.so's "crash" function and I get the infinite loop of r.e. 217's, never returning to the main program at all. I understand that it's only possible to have one signal handler installed at a time (which, in this example, I'm perfectly happy with; HookSignal does exactly what I want), but it seems wrong that an unhandled exception in a library should cause your program to go into an infinite loop, rather than doing the same thing an unhanded exception would do in an executable. Thoughts? Should I log it as a bug? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: HookSignal, "halt", and unhandled exceptions
Jonas wrote: > It's probably caused by r14184, which was in response to > http://bugs.freepascal.org/view.php?id=14958 > The problem is probably that the lib's exit code is called both when the > library is unloaded > (in which case you don't want the process to terminate) and when the > "library" terminates > (either via an unhandled exception, or by calling halt). I can't say off-hand > how to decouple them, > but a patch would be welcome. > Jonas Hm, I see what you mean. I'm going to be on vacation for the next two weeks (up in the mountains away from computers, electricity, etc.) but I'll ruminate on it while I'm gone. In the meanwhile I've logged a mantis issue to track: http://bugs.freepascal.org/view.php?id=17383 Have a good weekend, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: TFileStream and stdin - how to make this work?
Could you use THandleStream (http://www.freepascal.org/docs-html/rtl/classes/thandlestream.html)? myInputStream := THandleStream.Create(StdInputHandle); ... -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: TFileStream and stdin - how to make this work?
See ./packages/fcl-base/examples/asiotest.pp in the FPC source. Also, google turned up: achenko.narod.ru/stdin2file.pas which seems to be something like what you're looking to do. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] setting variables with DWARF in gdb
When I compile an FPC program for debug with DWARF symbols, GDB seemingly ignores my commands to set variables or registers when debugging: With STABS (or whatever the default is, ie., -gw is not set): Breakpoint 1, DOIT () at /home/tlacuache/tmp/project1.lpr:14 14 writeln(MYVAR); (gdb) print MYVAR $1 = 1 (gdb) set MYVAR=32 (gdb) print MYVAR $2 = 32 With DWARF: Breakpoint 1, DOIT () at project1.lpr:14 14 writeln(MYVAR); (gdb) print MYVAR $1 = 1 (gdb) SET MYVAR=32 (gdb) print MYVAR $2 = 1 Am I doing something wrong? Should I log a bug in mantis? -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: setting variables with DWARF in gdb
I *was* doing something wrong... doing a ":=" (pascal-style assignment) rather than just "=" seems to work Ok. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com On Fri, Oct 29, 2010 at 10:58 AM, Seth Grover wrote: > When I compile an FPC program for debug with DWARF symbols, GDB > seemingly ignores my commands to set variables or registers when > debugging: > > With STABS (or whatever the default is, ie., -gw is not set): > > Breakpoint 1, DOIT () at /home/tlacuache/tmp/project1.lpr:14 > 14 writeln(MYVAR); > (gdb) print MYVAR > $1 = 1 > (gdb) set MYVAR=32 > (gdb) print MYVAR > $2 = 32 > > With DWARF: > > Breakpoint 1, DOIT () at project1.lpr:14 > 14 writeln(MYVAR); > (gdb) print MYVAR > $1 = 1 > (gdb) SET MYVAR=32 > (gdb) print MYVAR > $2 = 1 > > Am I doing something wrong? Should I log a bug in mantis? > > -SG > > -- > This email is fiction. Any resemblance to actual events > or persons living or dead is purely coincidental. > > Seth Grover > sethdgrover[at]gmail[dot]com > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] PowerPC Linux and endian modes
Greetings! Wikipedia (http://en.wikipedia.org/wiki/PowerPC#Endian_modes) states: "Most PowerPC chips switch endianness via a bit in the MSR (Machine State Register), with a second bit provided to allow the OS to run with a different endianness." So the way I am understanding this is that the PPC architecture is capable of running in little-endian mode depending on a register flag that can be set. And that's about the end of my knowledge on the subject. My question is this: does anyone have any experience with running PPC in little endian mode? And would FPC-compiled programs (specifically I'm cross compiling to powerpc-linux from x86_64-linux) targeted at PPC work in a little endian mode setup? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: PowerPC Linux and endian modes
Henry and Jonas, thanks a lot for your responses and giving me an idea of at least where I'd want to start looking if that were the case. Honestly it's something of a pipe dream at the moment, so who knows if I'll even go down that path, but you've given me a place to begin if I do. Have a good weekend, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover On Thu, May 19, 2011 at 4:39 PM, Seth Grover wrote: > Greetings! > > Wikipedia (http://en.wikipedia.org/wiki/PowerPC#Endian_modes) states: > > "Most PowerPC chips switch endianness via a bit in the MSR (Machine > State Register), with a second bit provided to allow the OS to run > with a different endianness." > > So the way I am understanding this is that the PPC architecture is > capable of running in little-endian mode depending on a register flag > that can be set. And that's about the end of my knowledge on the > subject. > > My question is this: does anyone have any experience with running PPC > in little endian mode? And would FPC-compiled programs (specifically > I'm cross compiling to powerpc-linux from x86_64-linux) targeted at > PPC work in a little endian mode setup? > > Thanks, > > -SG > > -- > This email is fiction. Any resemblance to actual events > or persons living or dead is purely coincidental. > > Seth Grover > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] status of sparc solaris support
Quick question: http://freepascal.org says: "It is available for different processors: Intel x86, Amd64/x86_64, PowerPC, PowerPC64, Sparc, ARM." "The following operating systems are supported: Linux, FreeBSD, Haiku, Mac OS X/Darwin, DOS, Win32, Win64, WinCE, OS/2, Netware (libc and classic) and MorphOS." Then, lower, it lists: "Sparc architecture - 16 MB of RAM is required. Runs on any Sparc Linux installation (solaris is experimental)." Most of the references to Sparc/Solaris that I'm finding on the mailing list and whatnot are quite old. Can someone who knows give me a quick rundown as to what the status of Solaris on Sparc is? I'm specifically looking to port a Linux shared library to solaris on sparc. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] status of sparc solaris support
Mark, Jonas, and Pierre, thanks for your responses. I'll give it a shot and see how it goes. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] array of const and longword
I've got a routine that takes an "array of const" argument, then loops through the arguments looking at args[i].vtype and and doing something based on the VType value of each argument. Works like a charm. However, I've noticed that while there's a vtInteger type, a vtInt64 type, and a vtQWord type, there is no vtLongWord type. This means that any longwords that get passed in get treated as longints in my function. It's not a huge deal, since it's basically just a logging/debugging routine, but is there any way around this, other than casting it as an int64 or a qword or something on the caller side? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Free Pascal 2.6.0rc1 released
> We have placed the first release-candidate of the Free Pascal Compiler > version 2.6.0 on our ftp-servers. Congratulations! That's an impressive list of new features. I've been anticipating this release for some time. A couple of questions: where can this be found in svn? I don't see a tag for it, and fixes_2_6 hasn't been modified for 8 weeks or so. Secondly, will there be additional merges from trunk to fixes_2_6? If I recall the last time I checked the page with the list of potential merges from trunk to fixes_2_6 I believe it was quite long. Particularly I was hoping for revision 19036 (resolving issue 19404, fixing shared library loading and unloading for Linux platforms) to make it into the 2.6 release. Again, congratulations. I'll start using the release candidate next week at work and will report any issues I find. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Free Pascal 2.6.0rc1 released
Jonas, thanks for the link. For some reason it wasn't showing up on the viewvcs interface until I cleared my browser cache and refreshed. Thanks again. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FpGetRLimit and FpSetRLimit reference an undefined symbol
When I attempt to use fpgetrlimit and fpsetrlimit from the baseunix unit (see http://www.freepascal.org/docs-html/rtl/baseunix/fpgetrlimit.html and http://www.freepascal.org/docs-html/rtl/baseunix/fpsetrlimit.html), compilation fails with: undefined reference to `FPC_SYSC_GETRLIMIT' This happens targetting Linux for both i386 and x86_64. Is this a bug? Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: FpGetRLimit and FpSetRLimit reference an undefined symbol
>> Yes, it seems like a missing public alias for the FpGetRLimit function in >> the Linux system unit. > I added it. Thank you both. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover ` ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: [regex] : Is someone use SynRegExpr ? RegExpr2 vs SynRegExpr
Personally I use RegExpr Studio's TRegExpr (http://www.regexpstudio.com/TRegExpr/TRegExpr.html). It works great. I've used it in Delphi, Kylix, and FPC/Lazarus. Nothing to install just a single .pas file to use. -Seth Grover ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] reference to dynamic libraries on web site
I was looking this morning at the "Future Plans" page (http://freepascal.org/future.html) reading about the plans for 2.2. One of the items made me curious: - Support for dynamic libraries I know Free Pascal already allows me to create .dll's and .so's, so what exactly does this refer to? Sorry if the question is noob-ish. Thanks, SG -- Seth Grover sethdgrover[at]gmail[dot]com http://grovers.us/seth Who is John Galt? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] library initialization and deinitialization
I've got a shared library (.so) I wrote in C, with initialization and
finalization code declared by using the GCC attributes constructor and
destructor. These init and fini functions simply print out "start" and
"stop" to stdout. The .so exports one function, which prints out
"Hello".
I've got a test program (also written in C) which calls the .so's
function. What I see on stdout is
start
Hello
stop
Just like you'd expect.
I wrote a Free Pascal test program which also uses the .so. However,
what I see is this:
start
Hello
So for some reason, the fini never seems to get called! I thought this
was strange, so I wrote a similar library in free pascal:
==
library subs;
procedure SayHello (); cdecl; export;
begin
writeln('Hello ');
end;
exports
SayHello;
initialization
writeln('start');
finalization
writeln('done');
end.
==
Again, I ran a c test program against it and a fpc test program
against it. The C program's output was:
start
Hello
stop
The freepascal program's output was:
Hello
What's going on here?
With humble thanks,
Seth Grover
--
Seth Grover
sethdgrover[at]gmail[dot]com
http://grovers.us/seth
Who is John Galt?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: library initialization and deinitialization
A bug report (with sample code reproducing the behavior) has been logged. http://freepascal.org/mantis/view.php?id=9089. Probably should have done that before I emailed the mailing list. Sorry. -SG -- Seth Grover sethdgrover[at]gmail[dot]com http://grovers.us/seth Who is John Galt? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] backport 2.3.1 fix to 2.2.x fixes branch?
(Apology ahead of time if my question is bad etiquette...) I've been tracking an issue for a while: http://bugs.freepascal.org/view.php?id=8730 http://bugs.freepascal.org/view.php?id=9089 and am delighted to see it's been marked as fixed in 2.3.1. I grabbed the fixes_2_2 branch in hopes the change had been backported, but it doesn't appear the issue is resolved in that branch. I'm trying to facilitate a switch from kylix to freepascal in my company, and being able to have libraries initialize correctly is really important, but I'm reluctant to suggest we use the 2.3.x trunk in production. So my question is, how generally does a fix get backported to the fixes branch? Barring that, does anyone know of a way I can manually make sure the initialization code gets called? Can I directly call "initialize" somehow? Thanks a lot, Seth Grover -- Good news, everyone! Seth Grover sethdgrover[at]gmail[dot]com http://grovers.us/seth ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: backport 2.3.1 fix to 2.2.x fixes branch?
> If the fix is not too invasive (i.e., its effects are generally > overseeable), and if it has been in 2.3.1 for a while and no bad > effects are reported, then it will be merged after a while. These > particular fixes will be merged at some time in the future, but I > don't know when yet exactly. If you can test the fixes in trunk and > report whether or not everything indeed works now for you, that would > be very helpful. > Jonas, Thank you for your response! I grabbed 2.3.1 from subversion and ran both tests attached to bug 9089. The initialization code in the .so's are indeed being called now. Finalization is not, but I read somewhere else that that is another known issue, and, for me at least, that's not as big a deal. I would have reported these results in the bug itself, but I can't seem to find a way for mantis to let me comment on them now that it's closed. My setup is Free Pascal Compiler version 2.3.1 [2008/04/01] for i386, running on Ubuntu Linux 2.6.22-14-generic 7.10 kernel. Thanks again for your help and for explaining how the merge process works. Hopefully in a while we'll see it merged back! Cheers, Seth ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] "assertion failed" testing merges into fixes branch
This morning I saw that r10664 merged revisions 10495-10497,10551,10554,10556-10559,10663 into the 2.2 fixes branch. I pulled down the changes, recompiled fpc, and ran the tests which were uploaded here: http://bugs.freepascal.org/view.php?id=9089 (here's the direct link to the file: http://bugs.freepascal.org/file_download.php?file_id=6363&type=bug). It looks like the INIT section is being called, but I also get an error: $ ./ptest INIT Test 0 Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! My setup: Free Pascal Compiler version 2.2.1 [2008/04/14] for i386 Ubuntu Linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux -SG -- Good news, everyone! Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: "assertion failed" testing merges into fixes branch
> In your source tree, check tests/webtbs/tw9089*.pp (compile tw9089[a- > d] and then run "LD_LIBRARY_PATH=. ./tw9089c" and "LD_LIBRARY_PATH=. ./ > tw9089d"). That's the test case I distilled from your test programs > and which works fine for me. I've googled a bit and found a very long > thread about the above assertion at > http://lists.debian.org/debian-glibc/2004/01/msg00189.html tw9089c returns: INIT INIT2 Test 0 Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! When I get home tonight I'll try it on another box to see if it's just something wrong with my configuration. By the way, thanks a lot, I really appreciate your efforts! -SG -- Good news, everyone! Seth Grover sethdgrover[at]gmail[dot]com http://grovers.us/seth ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: "assertion failed" testing merges into fixes branch
Okay, so I ran it on a different distribution and it worked fine... INIT INIT2 Test 0 FINI2 FINI No "assertion failed" message or anything of the sort. This second system I tried was: Linux 2.6.12-23mdk #1 Fri Jul 7 13:15:45 MDT 2006 i686 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz unknown GNU/Linux So ... what does that mean? -SG -- Good news, everyone! Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: "assertion failed" testing merges into fixes branch
> > What is the version of glibc on the machine that causes a problem? > $ /lib/libc.so.6 GNU C Library stable release version 2.6.1, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.2.1 (Ubuntu 4.2.1-5ubuntu4). Compiled on a Linux >>2.6.15.7<< system on 2007-09-30. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. Thanks, -SG -- Good news, everyone! Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: "assertion failed" testing merges into fixes branch
> I've tested on systems with glibc 2.3.6, 2.5 and 2.7 and all work fine > (I don't have access to systems with other glibc versions installed). > I therefore think this was just a bug in 2.6.1 (possibly also 2.6), so > unless someone analyses the cause of the problem with glibc 2.6.1, I'm > not going to spend time on this. Okay, if you've tested it on that many other platforms I'll take your word for it. Thanks again you for your effort! -SG -- Good news, everyone! Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] dereferenced pointer as open array argument
Imagine I have this function: procedure ArrayTest(const data : array of char); begin ... end; and in another routine I have a pchar variable. If I slice the array byte doing this: ArrayTest(myPChar[0..99]); then inside ArrayTest it will appear that data is 100 characters, which is exactly what I'd expect. However, it surprised me that this syntax was accepted (with a dereferenced pchar): ArrayTest(myPChar^); as well as this syntax (with a simple char): ArrayTest(myChar); In both of those cases, ArrayTest thinks it's got an array of length 1. My question is (and I know this is a long shot): is there some sort of compiler directive or directive I can include in my source code to disallow the syntax of my second and third examples, ie., to disallow passing a single element as an open array? Thanks, -SG ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] extreme memory growth using cthreads and default heap manager
I am experiencing a weird issue regarding threading and shared libraries
under Linux. I've boiled it down to a very simple test case in hopes you
can help me understand what I'm doing wrong.
I'm running this test with FPC 3.0 (built from source) on x86_64 Debian
Linux.
First, I have this shared library:
===
library fpcso1;
{$mode objfpc}{$H+}
uses
cthreads,
// cmem,
SysUtils;
procedure Blow; cdecl;
var
p : pbyte;
begin
p := GetMem(1024);
FreeMem(p);
p := nil;
end;
exports
Blow name 'fpcso1_blow';
end.
===
It is used by this program:
===
program fpcprog;
{$mode objfpc}{$H+}
uses
cthreads,
cmem,
Classes,
SysUtils,
DateUtils;
const
lib1Name = 'libfpcso1.so';
procedure fpcso1_blow; cdecl; external lib1Name;
var
finishedThreads : longint = 0;
runningThreads : longint = 0;
startedThreads : longint = 0;
type
TTestThread = class(TThread)
protected
procedure Execute; override;
public
constructor Create;
end;
constructor TTestThread.Create;
begin
inherited Create(true, 1024*1024);
FreeOnTerminate := true;
end;
procedure TTestThread.Execute;
begin
InterLockedIncrement(runningThreads);
try
fpcso1_blow();
finally
InterLockedIncrement(finishedThreads);
InterLockedDecrement(runningThreads);
end;
end;
procedure BeginTestThread();
var
tmpThread : TTestThread;
begin
tmpThread := TTestThread.Create();
tmpThread.Start;
end;
const
threadCount = 10;
threadMaxConcurrent = 30;
var
lastTime : TDateTime;
lastCount : longint = 0;
begin
lastCount := 0;
lastTime := now;
while (startedThreads < threadCount) do begin
if (runningThreads < threadMaxConcurrent) then begin
InterLockedIncrement(startedThreads);
BeginTestThread();
end else begin
sleep(1);
end;
if MilliSecondsBetween(lastTime, now) >= 1000 then begin
writeln(runningThreads, ' threads runningThreads, ',
finishedThreads, ' threads finished (',
finishedThreads-lastCount, '/sec)');
lastCount := finishedThreads;
lastTime := now;
end;
end;
while (runningThreads > 0) do begin
sleep(1000);
writeln(runningThreads, ' threads runningThreads, ', finishedThreads,
' threads finished (', finishedThreads-lastCount, '/sec)');
lastCount := finishedThreads;
end;
sleep(1000);
writeln(runningThreads, ' threads runningThreads, ',
finishedThreads, ' threads finished');
end.
===
When I execute the program, over the course of the ten seconds it takes
to run, I watch the process' memory usage grow to over a gigabyte:
1s 235.81 MiB
2s 351.34 MiB
3s 463.64 MiB
4s 575.35 MiB
5s 688.54 MiB
6s 799.47 MiB
7s 916.26 MiB
8s1.01 GiB
9s1.12 GiB
10s1.15 GiB
However, if I uncomment the "// cmem," line in the library, the memory does
not grow.
Why does using the default memory manager seem to leak memory like crazy if
I'm doing heavy threading? I'm setting FreeOnTerminate to true in
conjunction
with creating the thread suspended, then calling Start, which the
examples in the wiki and documentation seems to indicate is valid.
Is cmem *required* if I'm using threading on Linux? I hope not, because
while this example is boiled down to as simple as I could make it, I'm
having the same issue in my production application, in which I'm using my
own power-of-two memory manager, and I would really like to figure out
what I can do to continue to use my own memory manager, plus threading,
without it leaking so much memory for every thread that starts/finishes.
Thanks,
-Seth Grover
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] extreme memory growth using cthreads and default heap manager
Interesting: playing around with it some more, if I put an empty try/except block inside my library's function from the example I posted, it leaks the memory whether or not I'm using cmem. -SG -- Seth Grover Be kind to all of your neighbors Because they're just like you. And you're nothing special Unless they are too. On Thu, Dec 10, 2015 at 2:26 PM, Seth Grover wrote: > I am experiencing a weird issue regarding threading and shared libraries > under Linux. > ... > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
