Recent

Author Topic: Limiting the amount of data presented when hovering over a variable or structure  (Read 348 times)

440bx

  • Hero Member
  • *****
  • Posts: 1129
Hello,

A rather nice feature of the debugger in Lazarus is its presenting a nicely formatted popup window with the values of the fields (in the case of a structure.)

There are some times when that rather nice feature causes a problem.  If one hovers over a pointer to an allocated array that contains tens of thousands of records, the building of that nice popup window can take a very significant amount of time.

In cases of arrays, is it possible to tell the debugger to present only the first "n" entries ?

Thank you for your help.
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5631
    • wiki
What kind of structure?

Dyn array IIRC show 5 entries, and less for nested.

Static array can be set in the Tools > Option > Debugger
In the grid is an option MaxDisplayLengthForStaticArray

For all others you can limit the max memory that gdb will use. But then big structures will simply give an error, and that applies to watches too.


Those feature only exists for pure gdb. For gdb+fpdebug there are no options.

440bx

  • Hero Member
  • *****
  • Posts: 1129
Thank you for your help Martin.

What kind of structure?
A rather convoluted one.  None are static arrays nor FPC dynamic arrays.  They are all arrays of structures residing in memory blocks obtained using HeapAlloc.

Now, I have to apologize for the complexity of what follows, it's just to give an idea of what I am dealing with.

Code: Pascal  [Select]
  1. const
  2.   PARENT_WIDGET_ENTRIES_MAX_COUNT = 65535;
  3.  
  4. const
  5.   ORIGIN_FILES_MAX_COUNT          = 256 * 1024;
  6.   MATCHING_PARENTS_MAX            = 16;
  7.  
  8.  
  9.   TPARENT_WIDGET_ENTRY = record
  10.     { contains the Parented Widget name, the TPARENTS_FILES_LIST index of     }
  11.     { the file name that Parents the Widget and the name of the               }
  12.     { related target if the Parented Widget is Related to another Widget      }
  13.  
  14.     efi_WidgetName        : packed array[0..511] of char;
  15.     efi_WidgetNameUpper   : packed array[0..511] of char;
  16.     efi_ParentFileIndex   : integer;
  17.     efi_RelatedTo         : packed array[0..511] of char;
  18.     efi_RelatedToUpper    : packed array[0..511] of char;
  19.   end;
  20.   PPARENT_WIDGET_ENTRY   = ^TPARENT_WIDGET_ENTRY;
  21.  
  22.  
  23.   { array of pointers to TPARENT_WIDGET_ENTRY                                 }
  24.  
  25.   TPARENT_WIDGET_LIST    = record
  26.     efl_ParentedWidgetCount : integer;
  27.     efl_ParentedWidget      : array[0..PARENT_WIDGET_ENTRIES_MAX_COUNT - 1]
  28.                                  of TPARENT_WIDGET_ENTRY;
  29.   end;
  30.   PPARENT_WIDGET_LIST    = ^TPARENT_WIDGET_LIST;
  31.  
  32.  
  33.   { array of Widgets that Parent Widgets                                      }
  34.  
  35.   TPARENT_FILES_LIST = record
  36.     xfl_ParentFilesCount   : integer;
  37.     xfl_ParentFiles        : packed array[0..PARENT_FILES_MAX_COUNT  - 1] of
  38.                              packed array[0..PARENT_FILE_BUFFER_SIZE - 1] of
  39.                              char;
  40.   end;
  41.   PPARENT_FILES_LIST = ^TPARENT_FILES_LIST;
  42.  
  43.  
  44. type
  45.   { array of Origin Widgets                                                  }
  46.  
  47.   TORIGIN_FILE_ENTRY = record
  48.     WidgetsPointer              : pchar;
  49.     ReferenceCount              : ptruint;
  50.     MatchingParentWidgetIndexes : packed array[0..MATCHING_PARENTS_MAX]
  51.                                             of ptruint;
  52.   end;
  53.  
  54.   TORIGIN_FILE_LIST  = record
  55.     hfl_OriginFileCount  : integer;
  56.     hfl_OriginFiles      : packed array[0..ORIGIN_FILES_MAX_COUNT - 1]
  57.                                      of TORIGIN_FILE_ENTRY;
  58.   end;
  59.   PORIGIN_FILE_LIST = ^TORIGIN_FILE_LIST;
  60.  
  61.  
  62. { all of these variables point to blocka of memory allocated with HeapAlloc,  }
  63. { the blocks are VERY large, in some cases in the hundreds of megabytes and   }
  64. { may contain anywhere from 15,000 entry minimum to about 180,000 entries max }
  65.  
  66. var
  67.   ParentFilesList           : PPARENT_FILES_LIST;
  68.   ParentedWidgetsList       : PPARENT_WIDGET_LIST;
  69.   OriginWidgetsList         : PORIGIN_FILE_LIST;
  70.   OriginNullTerminated      : pchar;
  71.   OriginNullTerminatedSize  : ptruint;
  72.  


when the cursor (accidentally) hovers over either, the ParentFilesList or the parentedwidgetslist, I have to terminate Lazarus because it most likely won't finish in a "reasonable" amount of time (10+ minutes).

I try to not place the cursor over those pointers when debugging but, if it goes over one of those, the debugging session is for practical purposes, over.

I'd like to tell Lazarus to limit the number of entries displayed for any of those dynamically allocated arrays to 50 entries.

Right now, it seems that either Lazarus or GDB (or both) are trying to format about a 100 megs of stuff.  As totally expected, they are not going to get that done in any reasonable amount of time.


using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.