[fpc-pascal] Some RTL functions cry big tears when mixing Pchar and Ansistring/String

[md at rpzdesign.com]

I totally understand, but I did not discover the problem until
I was well into a larger project that I could not de-construct
to try to generate a reproducible sample.

I am under a time pressure, decided to start using using LAZ/FPC about 3 
months ago,
and when I starting running the program under load, it started to die.

So I cleaned up my string function calls, separated out the pchar calls,
and things just magically healed themselves.

The program passes ALL of my load testing and just keeps running.

Do not ask me to reproduce it since I cannot
and I do not dispute that in a single threaded
test application, that it works.

The problem is when you start building up a large pile of code
and then start up the high volume testing, things really show themselves.

The problem in this particular case is the the GDB back trace on segment 
fault was total garbage,
so I cannot use that to tell you where the bug is.

Trust me, I am putting my financial basis into the binary output
of the FPC compiler since I can produce a much larger quantity of code 
faster
for LInux and Mac than I can with GCC/Xcode.

But for those like me, this serves as a warning to pay attention to this 
aspect.

There is not some underlying instability, but I believe a certain 
combination of things
causes a pointer reference that is off into la-la land.

My problems were in Copy( ) and PosEx( ), nothing more.

You guys rock!

md










On 6/11/2013 9:03 AM, Antonio Fortuny wrote:
> Hi Folks.
>
> I don't know how Jeppe is playing around but because I want to make 
> sure FPC works preoperly I decided to take some time to see what happens
> Yhis is the code snippet I use in Win32 and Linux x86_64
> All are Lazaur 1.0.8
>
> Put the code under a TButton and send results to a TMemo:
>
> procedure TFrmMain.BtnTestClick(Sender: TObject);
> var
>   P: Integer;
>   str: String;
>   pc: PChar;
>   len: Integer;
> begin
>   str := 'http://bcms.webdev.tralala.com/testudf.php?action=goodanswer';
>   len := Length(str);
>   P := PosEx('bcms', str, 3);
>   Memo1.Lines.Add(Format('search "bcms" in %s: position %d', [str, P]));
>   pc := nil;
>   ReAllocMem(pc, len + 1);
>   Move(PChar(str)^, pc^, len);
>   pc[len] := #0;
>   P := PosEx('bcms', pc, 3);
>   Memo1.Lines.Add(Format('search "bcms" in %s: position %d', [str, P]));
> end;
>
> I've made the test with a PChar too
>
> TMemo.Lines shows:
> search "bcms" in 
> http://bcms.webdev.tralala.com/testudf.php?action=goodanswer: position 8
> search "bcms" in 
> http://bcms.webdev.tralala.com/testudf.php?action=goodanswer: position 8
>
> which, obviously looks correct. That's what I expect since more than 
> 15 years (beginning with Delphi and Pos function)
>
> Enjoy,
>
> Antonio.
> -- 
> Sita Software
> *Antonio Fortuny*
> Senior Software engineer
>
> 220, avenue de la Liberté
> L-4602 Niederkorn
> Tel.: +352 58 00 93 - 93
> www.sitasoftware.lu <http://www.sitasoftware.lu>
> Your IT Partner
>
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130611/e5c69672/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2306 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130611/e5c69672/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 921 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130611/e5c69672/attachment-0001.jpe>