https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
I'm 95%+ sure that this is a problem with qemu+newlib with the latter not
handling out-of-memory correctly. If I run the good program to the same
instruction that faults in the bad program, I see:
Breakpoint 2, _malloc_r (reent_ptr=0x49570 <impure_data>, bytes=134217732)
at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2353
2353 in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
(gdb)
Continuing.
Breakpoint 1, 0x00018bc0 in _malloc_r (reent_ptr=0x49570 <impure_data>,
bytes=<optimized out>)
at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2592
2592 in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
(gdb) x/i $pc
=> 0x18bc0 <_malloc_r+1092>: str r3, [r2, #4]
(gdb) info reg r2
r2 0x804aa40 134523456
(gdb) x/x $r2
0x804aa40: 0x00000000
(gdb) x/x 0x805b000
0x805b000: Cannot access memory at address 0x805b000
So the location to be written exists and is the last mapped page of memory.
In the 'bad' program, I see
(gdb) x/i $pc
=> 0x18bc0 <_malloc_r+1092>: str r3, [r2, #4]
(gdb) p $r2
$14 = 134522216
(gdb) p *$4
$15 = {prev_size = 0, size = 0, fd = 0x804a568, bk = 0x494c0 <__malloc_av_>}
(gdb) p/x $r2
$16 = 0x804a568
(gdb) x/i $r2
0x804a568: Cannot access memory at address 0x804a568
(gdb) info reg pc
pc 0x18bc0 0x18bc0 <_malloc_r+1092>
(gdb) x/x 0x8049ffc
0x8049ffc: 0x00000000
that is the location being written is not mapped (but the page before is), this
is despite the address being lower than in the 'good' version.
Note that the difference between the two addresses being written in the two
programs is exactly the same as the difference between the VMAs of the .bss
segment in the executable files.
Consequently, I don't think this is a bug that has been introduced by this
patch, but is most likely a latent issue in either qemu or newlib (or perhaps a
combination of the two).
