Hi All,

I encountered a very strange problem. The code looks like this:

//In Unit1.pas:
//sel is an object of TIntVector and
//TIntVector = specialize TVector<Integer>

*sel.Sort([soEliminateNA, soReversed]); *

//In vector.pas:
procedure TVector.Sort(Options: SortOptions);
var
  i, gap, order, first, last, pos: Integer;
  Temp: T;
begin
  *if FCount < 2 then** Exit;  <-- problem here*
  if soReversed in Options then order := 1 else order := -1;
  ... ...

My purpose is to skip sorting if the vector's element count is less than 2.

Now the problem is that this statement does not have any effect (see attached screenshot). The debugger refuse to stop on the breakpoint, but goes directly to the line below it!

What's more strange is that if I change the line to break after “then”, i.e.:

begin
*if FCount < 2 then*
* Exit;*

  if soReversed in Options then order := 1 else order := -1;
  ... ...

Now it worked!

I also wrote a simple test program, but can NOT reproduce this bug there.

My TVector source code is here:
https://github.com/xrfang/fpcollection/blob/master/src/units/vector.pas

Any help is greatly appreciated.

Sincerely,
Xiangrong

Could you please check/compare the generated assembler code? Use "-al" to have the compiler generate it and you'll need to look at the file where you specialized the TVector.

Regards,
Sven

Hi Sven,

I don't know how to find that, could you please explain? Attached dbg.tar.bz2 is the demo program and assembly code generated by the compile. Where is the "point of specialization" in that file?

My working program is quite complex, I copied part of the code related to this problem in snippet.pas

Thank you!
Xiangrong

2014-02-13 23:53 GMT+08:00 Sven Barth :

Is it just the debugger does not stop? But the statement is executed (stopping in the next line never happens with FCount >= 2)?

Check your setup
http://wiki.lazarus.freepascal.org/Debugger_Setup
- NO smartlinking
- NO optimization
-O1 is often, but not always ok, so if there is an issue, then use -O-

Your image does not show the "blue dots" in the gutter (where the breakpoint ,and green arrow are). That indicates there is something wrong with the debug info.

Or maybe you have 2 units of the same name ,and use relative path ( ../ )? This can cause problems in some cases. Because gdb does not always deal with the .. , and then the IDE must specify the unit by name only, which is ambiguous.

2014-02-14 0:16 GMT+08:00 Martin Frb :

​Debugger problem is minor. I know I am missing the blue dots here. But the MAJOR problem is that in the attached screenshot, FCount is 0, which is of course smaller than 2, but it does NOT Exit!

This caused a SIGSEGV because in the code below I do this:

last := FCount - 1;
FItems[last] ...      //<-- which results in FItems[-1];

And smartlinking never turned on, switching off optimization in lazarus does not help either.

Regards,
Xiangrong​

Hi Sven,

Sorry that I overlooked the problem. It is indeed a debugger problem. It just stopped on the next line, but if I continue it just quit the function nicely.

So, now the minor problem is, I don't have the blue dots :)

Sincerely,
Xiangrong

blue dots comes back after I switch back to O1...

Sorry for the false alarm... but this seems a debugger problem in lazarus anyway...

2014-02-14 0:34 GMT+08:00 Xiangrong Fang :

With -O2 and above the debugger does not always work.

In case of such optimization the debug info compiled into the exe by fpc is not always accurate.

It is not just blue dots, inspecting variables may show random data, ....

Debugging with O2 and up, if you must, requires to only look at the disassembler and register window. registers can only be trusted in the ttop stackframe. selecting any other may not show correct info.

Hi Martin,

2014-02-14 1:14 GMT+08:00 Martin Frb :

I never use optimization option other than O1, I think O1 is the default. As Sven suggested, I tried turning off optimization, and back on, still at O1 level.
​​

Sorry, then I misunderstood you.

So where the blue dots missing, while you where at -O-? Or where they missing at -O1, and after you went to -O-, compiled (run), and went back to -O-1 they came back?

In either case, they should be there with -O- and -O1 , so if that is all you changed, then maybe it needed a clean build, and by changing settings, you triggered this clean build.

---
Strange though, because without blue dots, normally breakpoints to not work, but yours did (on the wrong line, but it did break).

The only other thing I can think of is, if you have symlinks to your files, and did open them in the IDE via different links/original. And/or fpc used a different symlink than the IDE.

In that cases it can happen that the IDE believes you have 2 independent files, while really you got just one. However breakpoints will work, because the error gets corrected when the IDE gives the wrong path to gdb, and retries with filename (no path) only. then gdb will set the breakpoint.

It can also be that the debug information for generics is (still) a bit messed up (the newly generated code in the unit with the specialization needs to point to the source where the generic is declared).

@Xiangrong Fang: do you use 2.6.2 or 2.7.1?

Regards,
Sven

2014-02-14 14:45 GMT+08:00 Sven Barth :

@Xiangrong Fang: do you use 2.6.2 or 2.7.1? I use 2.6.2

​​

Could be that it works a bit better in 2.7.1 as I changed something some months ago... (no guarantees though)

Regards,
Sven