Recent

Author Topic: assignments tracking  (Read 1991 times)

lucamar

  • Hero Member
  • *****
  • Posts: 3025
Re: assignments tracking
« Reply #15 on: February 29, 2020, 03:44:02 pm »
Too bad the bugreport is closed because it is the bug.
Valgrind sees it as a bug. That is how it was found.

Valgrind (quite logically, yes) might see it as a bug but it isn't (usually) one for Free Pascal. Vars of type array [0..X] of char are assignment compatible with (or esily convertible to) almost all other string types, including pchar and friends which means that they do have an extra byte reserved which contains a terminating zero.

Of course one shouldn't rely on this internal implementation detail and go happily accessing the array beyond its boundaries or allocating one less byte than needed to include a formal terminating #00 (e.g. when passed to an API expecting pchar); if nothing else, doing that in full-debug mode will generate an "Index out of bounds" error. Not to mention that it is a logic error which can produce difficult to trace bugs (as any other off-by-one glitch).
« Last Edit: February 29, 2020, 03:46:22 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

mm7

  • Full Member
  • ***
  • Posts: 193
  • PDP-11 RSX Pascal, Turbo Pascal, Delphi, Lazarus
Re: assignments tracking
« Reply #16 on: February 29, 2020, 04:00:53 pm »
@marcov
Yes it looks right.
But Valgrind catches an overrun.
let me to debug it more....

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6616
  • Debugger - SynEdit - and more
    • wiki
Re: assignments tracking
« Reply #17 on: February 29, 2020, 05:19:05 pm »
I don't know what vgdb does or does different from gdb. The IDE is made for gdb (and gdb with english responses).

Besides, why attach? Let valgrind run to finish. You can then load the valgrind log into menu View > Leaks and traces. It allows to navigate the valgrind traces. (there may be fixes in 2.1 of which I am not sure if they were merged to 2.0.x)

Code: Pascal  [Select][+][-]
  1.  Conditional jump or move depends on uninitialised value(s)
Can be a false positive.
Code: Pascal  [Select][+][-]
  1. If boolflag then a := whatever;
  2. if (a=0) and boolflag then ...
The 2nd line will trigger it, if boolflag is false. But it does not matter, it will do the right thing.

mm7

  • Full Member
  • ***
  • Posts: 193
  • PDP-11 RSX Pascal, Turbo Pascal, Delphi, Lazarus
Re: assignments tracking
« Reply #18 on: February 29, 2020, 07:27:06 pm »
with more debugging I've found that it is looks like not a bug.
Valgrind complains on Conditional jump or move depends on uninitialised value(s)

==25638== Conditional jump or move depends on uninitialised value(s)
==25638==    at 0x45DA14: SYSTEM_$$_INDEXBYTE$formal$INT64$BYTE$$INT64 (x86_64.inc:509)
==25638==    by 0x46A0E3: fpc_chararray_to_ansistr (astrings.inc:587)
...

this happens at x86_64.inc:509 in assembler code.
test   %eax, %eax
it is 4 bytes comparison and value is 2 bytes long. May be that is why?
eax is populated with result bits from previous 16 bytes comparison operation.

@Martin_fr
>why attach?
it would be nice to attach to alive program to see current values.

> load the valgrind log into menu View > Leaks and traces
Cool! I'll try.

mm7

  • Full Member
  • ***
  • Posts: 193
  • PDP-11 RSX Pascal, Turbo Pascal, Delphi, Lazarus
Re: assignments tracking
« Reply #19 on: February 29, 2020, 09:42:51 pm »
No. An actual issue (or not) is not even there.
It is somewhere in loading image resource into ImageList.

I can reproduce the issue only by following:
1. Create Application project
2. Drop ImageList on the Form
3. Load a picture into ImageList

-----
It looks like it is a false positive of Valgrind.
If variable Signature is local it shows mem error "Conditional jump or move depends on uninitialised value(s)".

file imglist.inc
Code: Pascal  [Select][+][-]
  1. procedure TCustomImageListResolution.ReadData(AStream: TStream);
  2. var
  3.   Signature: TImageListSignature;
  4. ...
  5.  

Valgrind is happy as soon as Signature is moved outside of the procedure.
So it does not like arrays in stack. But is Ok with same arrays in heap.

In simple program test it also depends on a size of array.
16,32 are ok, but 1,2,4,8 show the error.

« Last Edit: February 29, 2020, 11:17:46 pm by mm7 »

jamie

  • Hero Member
  • *****
  • Posts: 3528
Re: assignments tracking
« Reply #20 on: March 01, 2020, 02:16:28 am »
Looks like word alignment is assumed somewhere.. And maybe it shouldn't be?
The only true wisdom is knowing you know nothing

mm7

  • Full Member
  • ***
  • Posts: 193
  • PDP-11 RSX Pascal, Turbo Pascal, Delphi, Lazarus
Re: assignments tracking
« Reply #21 on: March 04, 2020, 06:29:59 pm »
I looked there. I am not a guru of assembler. But I saw that there is MMX call to find #0 end of ansistring. It is done on a preallocated 16 bytes buffer. 2 bytes of the source var is copied into the 16 bytes buffer, then MMX scans it, gets the result, masks it for 2 bytes only. All is fine. But it looks like Valgrind still takes scanning of other 14 bytes as uninitialized access, and treats the IF as a bad jump.
I am not sure if it is good or not idea to use MMX for just 2 bytes blocks. To me it is looks overkill.
May be it is done this way because I've turned off all optimization when recompiled RTL.
Anyway, it is not a bug, rather Valgrind's logical false positive.

 

TinyPortal © 2005-2018