Recent

Author Topic: Can this cause AV?  (Read 1766 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 14377
  • Sensorship about opinions does not belong here.
« Last Edit: March 01, 2024, 02:05:47 pm by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9900
  • Debugger - SynEdit - and more
    • wiki
Re: Can this cause AV?
« Reply #16 on: March 01, 2024, 04:00:55 pm »
Oh, btw, if it is threaded: AnsiStrings are only 99% thread safe.

If you have a global var that has a string with content (and that isn't a constant in the program code.
Then Thread1:
Code: Pascal  [Select][+][-]
  1. MyGlobalVar := '';
While Thread2:
Code: Pascal  [Select][+][-]
  1. LocalVar:= MyGlobalVar;

"LocalVar" can end up with a dangling pointer. If, and only if at that time "MyGlobalVar" was the only reference to the string.

The refcounting itself is thread save. But the alloc/dealloc is not. So LocalVar could be a pointer to the released memory.

Though, I don't think you suffer the above. This is a race condition with an extremely low likelihood of happening. So you would probably get the error once a year.

Fibonacci

  • Sr. Member
  • ****
  • Posts: 419
Re: Can this cause AV?
« Reply #17 on: March 01, 2024, 04:12:15 pm »
Any access to shared variables is wrapped around critical sections (unless I missed something). I narrowed down the leak to a single class now, so I will rewrite it carefully and hope this is it :) This class fires as many threads as are CPU cores available and do intensive operations on multidimensional arrays of records.

Thaddy

  • Hero Member
  • *****
  • Posts: 14377
  • Sensorship about opinions does not belong here.
Re: Can this cause AV?
« Reply #18 on: March 01, 2024, 04:16:58 pm »
Should be as many CPU cores available - 1 of course......
1 is for the controlling interface.
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5486
  • Compiler Developer
Re: Can this cause AV?
« Reply #19 on: March 01, 2024, 08:27:57 pm »
Why? "Self := nil" would not set the callers variable to nil. And the local variable "Self" itself is definitely not used after that (part of the concept is, that it freeing it is the last thing in the method.
No. Look at the implementation of freeandnil. That is for a reason.

It will still only change the value of Self inside the method that called FreeAndNil and not in the caller of that method, because for classes the Self parameter is passed in by-value.

lainz

  • Hero Member
  • *****
  • Posts: 4470
    • https://lainz.github.io/
Re: Can this cause AV?
« Reply #20 on: March 01, 2024, 09:22:06 pm »
Quote
Can this cause AV?

For those non english masters, what is AV?

tetrastes

  • Sr. Member
  • ****
  • Posts: 483
Re: Can this cause AV?
« Reply #21 on: March 01, 2024, 09:36:34 pm »
Quote
Can this cause AV?

For those non english masters, what is AV?

Access violation

jamie

  • Hero Member
  • *****
  • Posts: 6130
Re: Can this cause AV?
« Reply #22 on: March 01, 2024, 11:42:33 pm »
What I find is this, optimization changes the whole story here.

01 uses Ansi Assign of the string on the return which copies over the contents of the class data string.

02 and up looks like it is making a reference to the string?

 Anyone that would like the see the ASM code in the finish method can see this playing with the opto levels.

 So I guess it's possible some strings and pointers to could be getting clobbered.

Just an observation.

maybe this may work?
Code: Pascal  [Select][+][-]
  1. function tclassEx.finished: string;
  2. begin
  3.   SetLength(Result, Length(SomeData));
  4.   Move(PChar(SomeData)^,Pchar(Result)^,Length(SomeData));
  5.  // result := somedata;
  6.   self.Free;
  7. end;                    
  8.  

« Last Edit: March 01, 2024, 11:49:19 pm by jamie »
The only true wisdom is knowing you know nothing

440bx

  • Hero Member
  • *****
  • Posts: 4063
Re: Can this cause AV?
« Reply #23 on: March 02, 2024, 12:09:40 am »
Quote
Can this cause AV?

For those non english masters, what is AV?

Access violation
and depending on the context it could also be Anti-Virus (probably everyone knows that one)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

lainz

  • Hero Member
  • *****
  • Posts: 4470
    • https://lainz.github.io/
Re: Can this cause AV?
« Reply #24 on: March 02, 2024, 12:22:43 am »
Quote
Can this cause AV?

For those non english masters, what is AV?

Access violation
and depending on the context it could also be Anti-Virus (probably everyone knows that one)

Yes, on my mind was only AntiVirus-

Thanks.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9900
  • Debugger - SynEdit - and more
    • wiki
Re: Can this cause AV?
« Reply #25 on: March 02, 2024, 12:37:09 am »
What I find is this, optimization changes the whole story here.

01 uses Ansi Assign of the string on the return which copies over the contents of the class data string.

02 and up looks like it is making a reference to the string?

Not sure what you mean....

Code: Pascal  [Select][+][-]
  1.  result := somedata;
should just increment the refcount (unless somedata is an expression with operators....)
Just wildly guessed "UniqueString(result)"?


For the "move" code, be aware, that "result" for a function returning a string, is a "var param" => so you get passed in the variable to which the caller assigns (or sometimes a temp var as in between).
SetLength does make it unique though.

However, that should not make a difference. (Unless maybe if you do pchar access to the string)

 

TinyPortal © 2005-2018