FastMM4 for extended stored procedures DLLs under SQL Server

Thread View: borland.public.delphi.language.basm

5 messages

[T] Back to Threads [V] Tree View [G] Group Articles

5 total messages Started by ggeshev Tue, 17 Jun 2008 09:41

#313

Author: ggeshev
Date: Tue, 17 Jun 2008 09:41

107 lines
3160 bytes

Hello!



My company developed a huge project. Problems with memory usage pushed us 
toward memory manager replacement. We chose FastMM478. According to rules 
described in FastMM4_Readme.txt file from the downloaded folder I replaced 
the default Borland memory manager.



For all the client side of our application and also for all the server side 
we do not experience no problems after replacement.

But we have another part of the project which is a set DLLs which implement 
extended stored procedures for MSSQL Server. Any of these DLLs has "uses" 
clause like this :

library MSSQLFunc;



uses

  FastMM4 in 'FastMM4.pas',

  SysUtils,

  Classes,

  Windows,

  Variants :





For these DLLs I switched on these FastMM options:
{$define AssumeMultiThreaded}

{$define NeverUninstall}

{$define NoMessageBoxes}



When using the DLLs now we experience a crash - SQL Server process crashes, 
not right in the beginning but after a while. And because of the fixed 
moment of crash I began to experiment what conditions could I use to avoid 
the crash. I began choosing different FastMM options switching ON and OFF. 
Finally when I compiled with "{$define FullDebugMode}" everything was good 
and no crash was observed.

Unfortunately this is unsuitable because of the heaviness of the 
FullDebugMode. We expect a speed impact in that case.



Something more. See where the crash is:

function ConceptTools_UpStr(s:string):string;

var

  q:string;

  i:integer;

begin

  q:='';

  if length(s) > 0 then

    for I := 1 to length(s) do

      q:=q+UpCase(s[i]);         ?--- when the "i" has a value of 4, code 
crashes here



  ConceptTools_UpStr := q;

end;





Two reasons make me think the problems is in FastMM4:

  1.. The exception is on such a place that is so close to mere memory 
operations. Inside Borland procedure "UpCase" you can see a lot of assembler 
code. No ours instance of object is involved.
  2.. Good behavior when "{$define FullDebugMode}"




Please someone has any proposals what can be done?

I am ready to send all the Delphi code of all the DLLs.



Thank you!

Re: FastMM4 for extended stored procedures DLLs under SQL Server

#317

Author: Pierre le Riche
Date: Wed, 18 Jun 2008 12:20

28 lines
2308 bytes

>       q:=q+UpCase(s[i]);         ?--- when the "i" has a value of 4, code 
> crashes here

FullDebugMode is less concurrent than normal mode, so if you have 
multithread related bugs in your code it is possible that it could crash 
in normal mode but not FullDebugMode.

You should be very careful how you share strings between threads, since 
many string operations are not thread safe.

Remember that strings are reference counted, so if you assign one string 
to another they will actually share the same string data (unless you 
force the creation of a new copy). This can lead to all kinds of 
problems if both threads later try to modify the string data at the same 
time. If you're only going to be reading the string data, then it's ok, 
but once you start modifying strings you have to be very careful.

The advice I can give you is to try and avoid passing string data 
between threads if you can. If you do need to pass string data between 
threads, ensure that each thread gets its own copy of the string data by 
using SetLength or SetString.

Perhaps as a test you could replace all your "string" declarations with 
"WideString" declarations. Since WideString is not reference counted it 
is less susceptible to threading issues.

Regards,
Pierre

Re: FastMM4 for extended stored procedures DLLs under SQL Server

#326

Author: Nicholas Sherlock
Date: Thu, 19 Jun 2008 00:21

8 lines
1539 bytes

Pierre le Riche wrote:
> You should be very careful how you share strings between threads, since 
> many string operations are not thread safe.

Didn't strings become thread safe in Delphi 5?

Cheers,
Nicholas Sherlock

Re: FastMM4 for extended stored procedures DLLs under SQL Server

#329

Author: Primoz Gabrijelcic
Date: Thu, 19 Jun 2008 08:13

10 lines
1211 bytes

> The advice I can give you is to try and avoid passing string data
> between threads if you can. If you do need to pass string data
> between threads, ensure that each thread gets its own copy of the
> string data by using SetLength or SetString.

UniqueString is your friend, too.

-- 
Primoz
[http://thedelphigeek.com]

Re: FastMM4 for extended stored procedures DLLs under SQL Server

#330

Author: Martin James
Date: Thu, 19 Jun 2008 08:36

26 lines
2097 bytes

"Nicholas Sherlock" <N.sherlock@gmail.com> wrote in message 
news:4859a673@newsgroups.borland.com...
> Pierre le Riche wrote:
>> You should be very careful how you share strings between threads, since 
>> many string operations are not thread safe.
>
> Didn't strings become thread safe in Delphi 5?
>

Partially, but you can still get into trouble.

Delphi manages the strings by reference counting.  This if fine until a 
string reference leaves one thread and signaled into another.  Delphi has no 
way of understanding that a windows API call has taken ownership of the 
string to communicate it to another thread and so is quite happy to 
deallocate the string at the end of the method that dispatched it.  When the 
consumer thread gets the reference it is long dead :(

I dodge the issue by always communcating object instances.  Luckily, Delphi 
has no garbage-collection that might destroy an object that seemingly no 
longer has any reference to it, (eg. because the only ref. remaining is in 
the lParam of a posted message).

Rgds,
Martin

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads