[Bug tdep/26362] New: gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[Bug tdep/26362] New: gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

            Bug ID: 26362
           Summary: gdb/utils.c:671: internal-error: virtual memory
                    exhausted: can't allocate 187647121162241 bytes
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On openSUSE tumbleweed:
...
(gdb) PASS: gdb.fortran/mixed-lang-stack.exp: lang=auto: set language auto
bt^M
#0  breakpt () at
/home/abuild/rpmbuild/BUILD/gdb-10.0.50.20200806/gdb/testsuite/gdb.fortran/mixed-lang-stack.f90:37^M
#1  0x0000aaaaaaaab5d8 in mixed_func_1h () at
/home/abuild/rpmbuild/BUILD/gdb-10.0.50.20200806/gdb/testsuite/gdb.fortran/mixed-lang-stack.f90:115^M
#2  0x0000aaaaaaaaafd8 in mixed_func_1g (obj=...) at
/home/abuild/rpmbuild/BUILD/gdb-10.0.50.20200806/gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp:77^M
#3  0x0000aaaaaaaab020 in mixed_func_1f () at
/home/abuild/rpmbuild/BUILD/gdb-10.0.50.20200806/gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp:84^M
#4  0x0000aaaaaaaaafbc in mixed_func_1e () at
/home/abuild/rpmbuild/BUILD/gdb-10.0.50.20200806/gdb/testsuite/gdb.fortran/mixed-lang-stack.cpp:67^M
#5  0x0000aaaaaaaab5bc in mixed_func_1d (a=1, b=2, c=3, d=(4,5),
str=../../gdb/utils.c:671: internal-error: virtual memory exhausted: can't
allocate 187647121162241 bytes.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
FAIL: gdb.fortran/mixed-lang-stack.exp: lang=auto: bt (GDB internal error)
...

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

[Bug tdep/26362] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Build|                            |aarch64-linux-gnu
             Target|                            |aarch64-linux-gnu
               Host|                            |aarch64-linux-gnu

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

[Bug tdep/26362] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan.hayward at arm dot com

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|gdb/utils.c:671:            |[aarch64] gdb/utils.c:671:
                   |internal-error: virtual     |internal-error: virtual
                   |memory exhausted: can't     |memory exhausted: can't
                   |allocate 187647121162241    |allocate 187647121162241
                   |bytes                       |bytes

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[alahay01 at gcc dot gnu.org]

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

Alan Hayward <alahay01 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alahay01 at gcc dot gnu.org,
                   |                            |luis.machado at linaro dot org

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #1 from Luis Machado <luis.machado at linaro dot org> ---
Could you please attach a tarball of the test run and the log file? So
gdb/testsuite/outputs/gdb.fortran/mixed-lang-stack/* and gdb/testsuite/gdb.log.

I couldn't reproduce this in my Ubuntu environment, and I don't have a OpenSUSE
system handy.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12762
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12762&action=edit
pruned gdb.log file

I've pruned the gdb.log file to just this test-case.

I don't have access to the build artefacts of obs, so in order to get the gdb
test dir I need to find an aarch64 machine and setup building and testing gdb
myself.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #3 from Luis Machado <luis.machado at linaro dot org> ---
I can't reproduce this with my local setup (Ubuntu 18.04). I'm guessing we're
passing down a bogus/garbage value to malloc, or a negative value.

A backtrace from GDB's crash would be helpful to try to narrow this down.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #3)
> I can't reproduce this with my local setup (Ubuntu 18.04). I'm guessing
> we're passing down a bogus/garbage value to malloc, or a negative value.
> 
> A backtrace from GDB's crash would be helpful to try to narrow this down.

Yeah.  If gdb would produce a backtrace upon assert, like gcc, I would already
have this available ( FTR, mentioned this possibility here:
https://sourceware.org/pipermail/gdb/2020-July/048788.html ).

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
I've tried to reproduce the test on trunk with x86_64 (in a VM with openSUSE
tumbleweed installed), no luck.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12766
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12766&action=edit
gcc.log, gcc.sum, outputs/gdb.fortran/mixed-lang-stack/

Reproduced using:
- osc build \
    -M testsuite \
    openSUSE_Factory_ARM aarch64
- osc chroot openSUSE_Factory_ARM aarch64
- using gdb command line

gdb command line:
...
$ gdb \
  outputs/gdb.fortran/mixed-lang-stack/mixed-lang-stack \
  -batch \
  -ex "b breakpt" \
  -ex run \
-ex bt
Breakpoint 1 at 0x11ac: file mixed-lang-stack.f90, line 37.
a = 1, b = 2.000000, c = 3.000000e+00, d = (4.000000 + 5.000000i)
           1   2.00000000       3.0000000000000000                 
(4.00000000,5.00000000) this is a string from C

Breakpoint 1, breakpt () at mixed-lang-stack.f90:37
37        write(*,*) "Hello World"         ! Break here.
#0  breakpt () at mixed-lang-stack.f90:37
#1  0x0000aaaaaaaab5d8 in mixed_func_1h () at mixed-lang-stack.f90:115
#2  0x0000aaaaaaaaafd8 in mixed_func_1g (obj=...) at mixed-lang-stack.cpp:77
#3  0x0000aaaaaaaab020 in mixed_func_1f () at mixed-lang-stack.cpp:84
#4  0x0000aaaaaaaaafbc in mixed_func_1e () at mixed-lang-stack.cpp:67
#5  0x0000aaaaaaaab5bc in mixed_func_1d (a=1, b=2, c=3, d=(4,5),
str=../../gdb/utils.c:671: internal-error: virtual memory exhausted: can't
allocate 187647121162241 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it.  For instructions, see:
<http://bugs.opensuse.org/>.

../../gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate
187647121162241 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
Aborted (core dumped)
...

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Backtrace at abort:

Thread 1 "gdb" received signal SIGABRT, Aborted.
0x00004000009b9768 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00004000009b9768 in raise () from /lib64/libc.so.6
#1  0x00004000009a5da0 in abort () from /lib64/libc.so.6
#2  0x0000aaaaaafd3408 in dump_core () at ../../gdb/utils.c:204
#3  0x0000aaaaaafd9f6c in internal_vproblem (
    problem=0xaaaaab5f6e50 <_ZL22internal_error_problem.lto_priv.0>,
file=<optimized out>, 
    line=<optimized out>, fmt=<optimized out>, 
    ap=<error reading variable: Cannot access memory at address 0x0>)
    at ../../gdb/utils.c:414
#4  0x0000aaaaab12d3c8 in internal_verror (ap=..., fmt=<optimized out>, 
    line=<optimized out>, file=<optimized out>) at ../../gdb/utils.c:439
#5  internal_error (file=<optimized out>, line=<optimized out>, fmt=<optimized
out>)
    at ../../gdbsupport/errors.cc:55
#6  0x0000aaaaaafd3810 in malloc_failure (size=187647121162241) at
../../gdb/utils.c:671
#7  0x0000aaaaaafea8a8 in xcalloc (size=187647121162241, number=1) at
../../gdb/alloc.c:102
#8  xzalloc (size=<optimized out>) at ../../gdbsupport/common-utils.cc:28
#9  allocate_value_contents(value*) [clone .part.0] [clone .lto_priv.0]
(val=0xaaaaabdc46f0)
    at ../../gdb/value.c:1022
#10 0x0000aaaaaafec998 in allocate_value_contents (val=0xaaaaabdc46f0)
    at ../../gdb/value.c:3847
#11 value_fetch_lazy (val=0xaaaaabdc46f0) at ../../gdb/value.c:3921
#12 0x0000aaaaaafe39c0 in value_entirely_covered_by_range_vector (ranges=..., 
    value=0xaaaaabdc46f0) at ../../gdb/value.c:418
#13 value_entirely_optimized_out (value=0xaaaaabdc46f0) at
../../gdb/value.c:442
#14 value_check_printable (val=0xaaaaabdc46f0, stream=0xffffffffed98,
options=0xffffffffed68)
    at ../../gdb/valprint.c:1023
#15 0x0000aaaaaaf42b58 in common_val_print_checked (recurse=2, 
    language=0xaaaaab6405b0 <f_language_defn>, options=0xffffffffed68, 
    stream=0xffffffffed98, val=0xaaaaabdc46f0) at ../../gdb/valprint.c:1091
#16 print_frame_arg (fp_opts=..., arg=arg@entry=0xffffffffeea8) at
../../gdb/stack.c:489
#17 0x0000aaaaaaf46b8c in print_frame_args (fp_opts=..., func=<optimized out>, 
    frame=0xaaaaabc8e980, num=-1, stream=0xaaaaab96aa20) at
../../gdb/stack.c:887
#18 0x0000aaaaaaf49f38 in print_frame (sal=..., sal=..., print_args=<optimized
out>, 
    print_what=LOCATION, print_level=<optimized out>, frame=0xaaaaabc8e980,
fp_opts=...)
    at ../../gdb/top.c:102
#19 print_frame_info (fp_opts=..., frame=0xaaaaabc8e980, print_level=<optimized
out>, 
    print_what=LOCATION, print_args=<optimized out>, set_current_sal=0)
    at ../../gdb/stack.c:1113

#20 0x0000aaaaaaf4d538 in backtrace_command_1 (from_tty=0, count_exp=<optimized
out>, 
    bt_opts=..., fp_opts=...) at ../../gdb/stack.c:2079
#21 backtrace_command (arg=<optimized out>, from_tty=0) at
../../gdb/stack.c:2198
#22 0x0000aaaaaacbc524 in cmd_func (cmd=<optimized out>, args=<optimized out>, 
    from_tty=<optimized out>) at ../../gdb/cli/cli-decode.c:2181
#23 0x0000aaaaaaf9be1c in execute_command (p=<optimized out>, 
    p@entry=<error reading variable: value has been optimized out>, from_tty=0, 
    from_tty@entry=<error reading variable: value has been optimized out>)
    at ../../gdb/top.c:668
#24 0x0000aaaaaae0f818 in catch_command_errors (command=<optimized out>, 
    arg=<optimized out>, from_tty=<optimized out>) at ../../gdb/main.c:457
#25 0x0000aaaaab17a4e0 in captured_main_1(captured_main_args*) [clone
.constprop.0] (
    context=context@entry=0xfffffffff6f0) at ../../gdb/main.c:1218
#26 0x0000aaaaaac0756c in captured_main (data=0xfffffffff6f0) at
../../gdb/main.c:1239
#27 gdb_main (args=0xfffffffff6f0) at ../../gdb/main.c:1268
#28 main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:32
(gdb)

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
So, we're allocating type length for:
...
(gdb) up
#9  allocate_value_contents(value*) [clone .part.0] [clone .lto_priv.0]
(val=0xaaaaabdc46f0)
    at ../../gdb/value.c:1022
1022            ((gdb_byte *) xzalloc (TYPE_LENGTH (val->enclosing_type)));
...
which is type:
...
(gdb) p recursive_dump_type (val->enclosing_type, 0)
type node 0xaaaaabe871b0
name '<NULL>' (0x0)
code 0x2 (TYPE_CODE_ARRAY)
length 187647121162241
objfile 0xaaaaab96b910
target_type 0xaaaaaba9dc50
  type node 0xaaaaaba9dc50
  name 'character' (0xaaaaaba9dcd0)
  code 0x14 (TYPE_CODE_CHAR)
  length 1
  gdbarch 0xaaaaab8f57e0
  target_type 0x0
  pointer_type 0x0
  reference_type 0x0
  type_chain 0xaaaaaba9dc50
  instance_flags 0x0
  flags
  nfields 0 0x0
pointer_type 0x0
reference_type 0x0
type_chain 0xaaaaabe871b0
instance_flags 0x0
flags
nfields 1 0xaaaaabe872f0
  [0] bitpos 0 bitsize 0 type 0xaaaaabe87230 name '<NULL>' (0x0)
    type node 0xaaaaabe87230
    name '<NULL>' (0x0)
    code 0xc (TYPE_CODE_RANGE)
    length 4
    objfile 0xaaaaab96b910
    target_type 0xaaaaaba70980
      type node 0xaaaaaba70980
      name 'int' (0xaaaaab1bfee0)
      code 0x8 (TYPE_CODE_INT)
      length 4
      objfile 0xaaaaab96b910
      target_type 0x0
      pointer_type 0x0
      reference_type 0x0
      type_chain 0xaaaaaba70980
      instance_flags 0x0
      flags
      nfields 0 0x0
    pointer_type 0x0
    reference_type 0x0
    type_chain 0xaaaaabe87230
    instance_flags 0x0
    flags TYPE_UNSIGNED
    nfields 0 0xaaaaabe872b0
    low 1  high 187647121162241
$3 = void
...

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #9 from Luis Machado <luis.machado at linaro dot org> ---
That last low/high information seems bogus.

I get, on Ubuntu 18.04...

low 1  high 0

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #10 from Luis Machado <luis.machado at linaro dot org> ---
Also, length for me is 0, whereas your example shows 187647121162241.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #11 from Luis Machado <luis.machado at linaro dot org> ---
Ok. I may have found a clue.

The problematic binary seems to have the following for the str's type
description:

<1><1074>: Abbrev Number: 25 (DW_TAG_string_type)
    <1075>   DW_AT_string_length: 5 byte block: 99 46 3 0 0     (DW_OP_call4:
<0x1066>)
    <107b>   DW_AT_sibling     : <0x108a>

The working case (Ubuntu 18.04) seems to have the following:

<1><114c>: Abbrev Number: 27 (DW_TAG_string_type)
    <114d>   DW_AT_string_length: 5 byte block: 99 55 3 0 0     (DW_OP_call4:
<0x112d>)
    <1153>   DW_AT_byte_size   : 4
    <1154>   DW_AT_sibling     : <0x1162>

So it seems we're missing a DW_AT_byte_size entry.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #12 from Luis Machado <luis.machado at linaro dot org> ---
I wonder if this is a compiler issue instead.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #13 from Luis Machado <luis.machado at linaro dot org> ---
The array size is dynamically calculated, so it is slightly difficult to
examine that portion of the code without being able to reproduce it.

On a binary that does not crash, I can see the length being computed correctly
(23).

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[andrew.burgess at embecosm dot com]

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

Andrew Burgess <andrew.burgess at embecosm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrew.burgess at embecosm dot com

--- Comment #14 from Andrew Burgess <andrew.burgess at embecosm dot com> ---
When a DW_AT_string_length is present the DW_AT_byte_size tells us the size of
the length itself (on DWARF 4 and earlier, this changes on DWARF5).

When DW_AT_byte_size is missing GDB should assume the string length is the size
of a pointer on the target.

x86-64 was mentioned, so assuming the pointer size is 8-bytes, in comparison to
the working case where the DW_AT_byte_size tells us the length is a 4-byte
value, this is clearly a change.

Then when we look at the type dump Tom posted, we see the string high bound is
`187647121162241`, which in hex is `0xaaaa00000001`, so we can see that the
least significant 4-bytes make sense, while the upper bytes are corrupting the
length value.

I would agree that this looks like a compiler bug.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #15 from Luis Machado <luis.machado at linaro dot org> ---
Thanks for the explanation Andrew.

For aarch64-linux, this is also a change in behavior, as the pointer size is 8
bytes whereas the previous size was 4 bytes.

Is the assumption that the size is a pointer size correct? Is that what the
standard says or is something GDB assumes?

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #16 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #15)
> Thanks for the explanation Andrew.
> 
> For aarch64-linux, this is also a change in behavior, as the pointer size is
> 8 bytes whereas the previous size was 4 bytes.
> 
> Is the assumption that the size is a pointer size correct? Is that what the
> standard says or is something GDB assumes?

The standard says:
...
The string type entry may have a DW_AT_string_length attribute whose value is a
location description yielding the location where the length of the string is
stored in the program. The string type entry may also have a DW_AT_byte_size
attribute or DW_AT_bit_size attribute, whose value (see Section 2.21) is the
size of the data to be retrieved from the location referenced by the string
length attribute. If no (byte or bit) size attribute is present, the size of
the data to be retrieved is the same as the size of an address on the target
machine.
...

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #17 from Luis Machado <luis.machado at linaro dot org> ---
Ok. So GDB seems to be doing the right thing, but the compiler is not
generating information that is 8 bytes in size (my guess).

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #18 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #17)
> Ok. So GDB seems to be doing the right thing, but the compiler is not
> generating information that is 8 bytes in size (my guess).

I wonder though why max_value_size did prevent the allocation.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #19 from Luis Machado <luis.machado at linaro dot org> ---
I thought about that too.

The only way it would've bypassed the check is if length is less than or equal
to max_value_size. Is length cast to a signed integer when compared to
max_value_size (a signed int)?

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #20 from Luis Machado <luis.machado at linaro dot org> ---
OK. I've now reproduced this with trunk GCC on Ubuntu 18.04.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #21 from Luis Machado <luis.machado at linaro dot org> ---
The check in check_type_length_before_alloc fails because the type length
actually overflows the int type we're using to store it. This is incorrect. We
should use size_t instead.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #22 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, I think the test-case needs a fix for gcc-7 and earlier, something along
the lines of:
...
diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.c
b/gdb/testsuite/gdb.fortran/mixed-lang-stack....c
index 0d254cde2c6..39a0ba1f184 100644
--- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.c
+++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.c
@@ -22,8 +22,14 @@ struct some_struct
   float a, b;
 };

+#if __GNUC__ > 7
+typedef size_t fortran_charlen_t;
+#else
+typedef int fortran_charlen_t;
+#endif
+
 extern void mixed_func_1d_ (int *, float *, double *, complex float *,
-                           char *, size_t);
+                           char *, fortran_charlen_t);

 void
 mixed_func_1c (int a, float b, double c, complex float d, char *f,
...
[ Found at
https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html ]

Luis, what was the gcc version you used for the "DW_AT_byte_size   : 4" ? Was
that gcc 7?

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #23 from Luis Machado <luis.machado at linaro dot org> ---
It is GCC 7.5.0-3ubuntu1~18.04)

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #24 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #23)
> It is GCC 7.5.0-3ubuntu1~18.04)

Right, then there's no compiler bug, just a change in ABI.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[luis.machado at linaro dot org]

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

--- Comment #25 from Luis Machado <luis.machado at linaro dot org> ---
Interesting and sneaky.

You should be aware that my fix to the malloc sanity check makes the test pass
now, even though it attempts to allocate the large number of bytes and errors
out.

It just doesn't throw an internal error like before.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #26 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #25)
> Interesting and sneaky.
> 
> You should be aware that my fix to the malloc sanity check makes the test
> pass now, even though it attempts to allocate the large number of bytes and
> errors out.
> 
> It just doesn't throw an internal error like before.

I think I've analyzed that bit here: PR26390 -
"gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace".

If we consider the scope of this PR the internal-error, I think we are done
here.

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

--- Comment #27 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #22)
> Hmm, I think the test-case needs a fix for gcc-7 and earlier, something
> along the lines of:
> ...
> diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.c
> b/gdb/testsuite/gdb.fortran/mixed-lang-stack....c
> index 0d254cde2c6..39a0ba1f184 100644
> --- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.c
> +++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.c
> @@ -22,8 +22,14 @@ struct some_struct
>    float a, b;
>  };
>  
> +#if __GNUC__ > 7
> +typedef size_t fortran_charlen_t;
> +#else
> +typedef int fortran_charlen_t;
> +#endif
> +
>  extern void mixed_func_1d_ (int *, float *, double *, complex float *,
> -                           char *, size_t);
> +                           char *, fortran_charlen_t);
>  
>  void
>  mixed_func_1c (int a, float b, double c, complex float d, char *f,
> ...
> [ Found at
> https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html ]
> 

Done:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3d11c30a6e839cfc126353fd1b35960301a1b6a0

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

[Bug tdep/26362] [aarch64] gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 187647121162241 bytes

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #28 from Tom de Vries <vries at gcc dot gnu.org> ---
The root cause for the internal-error was fixed here:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6d8a0a5e90936d4bea9bf1ce9b4e1c22d9aaccae
.

The trigger for the internal-error was fixed as PR26390.

Marking this PR resolved-fixed.

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