[Bug gdb/17612] New: gdb should be able to clip large memory reads to a certain size

[Bug gdb/17612] New: gdb should be able to clip large memory reads to a certain size

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17612

            Bug ID: 17612
           Summary: gdb should be able to clip large memory reads to a
                    certain size
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

Someone on irc was having a problem printing a VLA (gdb ran out of memory) and
that got me wondering how gdb handles printing of large objects.

#include <stdlib.h>

struct big { char foo[1 * 1024 * 1024 * 1024]; };

int
main ()
{
  struct big *p = malloc (sizeof (*p));
  return 0;
}

Printing *p takes forever.
Plus it's not interruptable.

So there's two bugs here:
1) we should provide a way to clip the amount of memory read, akin to how we
clip how much we print with "set print elements".  Maybe we could use the same
parameter, I'm not sure.
2) this should be interruptable.
[I'll file a separate bug for this in a bit.]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17612] gdb should be able to clip large memory reads to a certain size

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17612

--- Comment #1 from dje at google dot com ---
Filed PR 17613 to cover the not interruptable part.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17612] gdb should be able to clip large memory reads to a certain size

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17612

--- Comment #2 from dje at google dot com ---
It's not the amount of memory read that is slowing things down here, though it
might still be nice to provide a knob - we don't want to accidently trip a
malloc failure.

What's taking forever in this example is computing the number of repeated
elements.  Change foo to 1M in size, and set target debug to 1 and it's easier
to see.

(gdb) set target debug 1
(gdb) p *p
target_thread_address_space (process 12972) = 1
native:target_xfer_partial (2, (null), 0x2dd1610, 0x0, 0x401ba8, 8) = 1, 8,
bytes =
 10 10 60 f7 ff 7f 00 00
native:target_xfer_partial (2, (null), 0x7f63eadcc010, 0x0, 0x7ffff7601010,
1048576) = 1, 1048576, bytes =
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
$1 = {

[long uninterruptable pause here]

  foo =     '\000' <repeats 1048575 times>
}
(gdb) 

Should the "repeats xxx times" calculation take into account "print elements" ?
Maybe "repeats at least 200 times" (where 200 is the value of "print elements")
?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17612] gdb should be able to clip large memory reads to a certain size

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17612

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #3 from Hannes Domani <ssbssa at sourceware dot org> ---
Isn't that what was implemented with "set max-value-size" (in version 7.11)?
If so then I think this can be closed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.