IDB maximum values at eval window per array

[alquimista]

Hello.

I hope that my doubt is in the correct forum.

I'm debugging some codes developed in mixing FORTRAN and C language. I'm using Intel Debugger, when I'm checking the values for one array (at the eval window) of aprox dimension 600 I just can see the first 200 values. It happens to me in all the vectors greater than 200, so I suppose that I can change the configuration or the memory reservation. I was looking for further information in Internet without success.

I ask for some help using IDB if it's posible or just DDD.

Thank you very much.

[Ron_Green]

Yes, I see this limitation also. In theory in gdb mode the command 'set print elements 1000' should override the default of 200 elements displayed. I've tried this in the command window without success. I have asked our IDB team for a way to unlimit the number of elements displayed.

[jimdempseyatthecove]

In your Watch window add

Array for 1:200
Array(201,:) for 201:400
Array(401,:) for 401:600
...

On the older version I get 1000 cells per view

Jim Dempsey

[alquimista]

Hallo Jim Dempsey,

I tried your advice. If I do "Array(201,:)" I obtain "Error: array has 1 dimension and 2 were specified", so it seems likeit expectto be amatrix. I tried with "Array(201:300) but it's shown the 100 positions with value "no value" butif Icheck Array(201) I obtain the expected value.


On the other hand I tried on theIDB console "set print elements 0" (to be thatunlimited) and "show print elements" obtaining "Limit on string chars or array elements to print is unlimited", but It doesn't works at the eval window.


Thanks.

[jimdempseyatthecove]

I am not a user of the IDB so I cannot test this out...

Most debuggers have a memory dump optiontaking an address together with type and optional repeat count. See if you can do something like (pseudo commands)

Dump loc(array(1)) astype for n locations/entities

Where type would be the data type in the array. As to whatthis syntax is for the IDB I do not know.

In Visual Studio on Windows you set a memory dump window starting at a location and then within the window you select the type of variables you want to look at (bytes,word, dword, qword, float, double, ... hex/decimal, ...). Eclipse on Linux has a similar memory dump capability. Iwould have to guess that your IDB has a similar functionality. The drawback of this is the addresses shown are typically in hex and not as an offset from the address expression entered into the dump command.

Jim Dempsey

[Ron_Green · Accepted solution]

The current debugger GUI limits strings and arrays to 200 elements. It's unfortunate, but there you have it. They were having issues with users trying to open up huge arrays and either crashing the debugger or having GUI slow to a snails pace. It takes a fair amount of resources for each element displayed.

BUT in a future idb they will allow users to specify elements with 'set print elements X' where X is the limit you set. I've tested an engineering version and it works well. I start up idb, then before running the program, in the command window, one can 'set print elements 1024' or some reasonable value. Then run, and display is what you'd expect - either the entire array up to 1024 elements.

there is nothing magic about '1024', for my simple testcase it worked well. If you have an array with 2Giga elements and you set the limit to that, well, enjoy the reboot of your system.

I will post more information when this version of IDB becomes available.

ron

[jimdempseyatthecove]

Ron, while I am not a user of the IDB I would imaging that when displaying an array of data that it presents to the user a window displaying some small number of lines with an elevator button for the user to scroll. And the current method of operation is to dump upto "print elements" limit to an internal text buffer then let the array view window scroll through this text buffer.

I would suggest you talk to your team and recommend that you have them change this to constitute the display window portion of the text buffer for the array and not the entire array. As they scroll up or down the missing portions are reconstituted. *** also when the scroll of the elevator button exceeds the reconstitution rate you leap ahead or behind instead of scrolling line by line up or down. In this manner an array of 2G elements will display as fast as it takes to paint the small window. Also, if scrolling the elevator button from top to bottom you will not experience the delay of dumping the 2G elements through the window.

Jim Dempsey