public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/67457] New: segfault in libbacktrace
@ 2015-09-05  7:22 Joost.VandeVondele at mat dot ethz.ch
  2015-09-08 13:49 ` [Bug other/67457] " ian at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2015-09-05  7:22 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

            Bug ID: 67457
           Summary: segfault in libbacktrace
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

gfortran on trunk uses libbacktrace to print backtraces on error. In an
out-of-memory situation, libbacktrace will fail to print a backtrace and
segfault instead. While having something like a backtrace would be nice (and
other compilers seem to manage), I guess that's difficult. For the segfault gdb
print this:

Starting program: /data/vjoost/gnu/bugs/a.out 
Operating system error: Cannot allocate memory
Allocation would exceed memory limit

Error termination. Backtrace:

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory

Program received signal SIGSEGV, Segmentation fault.
backtrace_free_locked (state=0x7ffff7ecc000, size=3912, addr=0x20b7) at
../../../gcc/libbacktrace/mmap.c:75
75            p->size = size;
(gdb) bt
#0  backtrace_free_locked (state=0x7ffff7ecc000, size=3912, addr=0x20b7) at
../../../gcc/libbacktrace/mmap.c:75
#1  backtrace_free (state=0x7ffff7ecc000, addr=0x20b7, size=3912,
error_callback=<optimized out>, data=<optimized out>)
    at ../../../gcc/libbacktrace/mmap.c:199
#2  0x00007ffff7fcd077 in backtrace_alloc (state=state@entry=0x7ffff7ecc000,
size=size@entry=8376, 
    error_callback=error_callback@entry=0x7ffff7ee8cd0 <error_callback>,
data=data@entry=0x7fffffffde90) at ../../../gcc/libbacktrace/mmap.c:148
#3  0x00007ffff7fcc7f8 in elf_initialize_syminfo (sdata=0x7ffff7ec0620,
data=0x7fffffffde90, error_callback=0x7ffff7ee8cd0 <error_callback>, 
    strtab_size=<optimized out>, strtab=<optimized out>, symtab_size=<optimized
out>, symtab_data=0x7ffff7eb5088 "", base_address=140737352400896, 
    state=0x7ffff7ecc000) at ../../../gcc/libbacktrace/elf.c:380
#4  elf_add (state=<optimized out>, descriptor=<optimized out>,
base_address=140737352400896, error_callback=<optimized out>,
data=0x7fffffffde90, 
    fileline_fn=fileline_fn@entry=0x7fffffffd998, found_sym=0x7fffffffda70,
found_dwarf=0x7fffffffd994, exe=0) at ../../../gcc/libbacktrace/elf.c:748
#5  0x00007ffff7fccc67 in phdr_callback (info=0x7fffffffd9e0, size=<optimized
out>, pdata=0x7fffffffda80) at ../../../gcc/libbacktrace/elf.c:903
#6  0x0000003ba4b26726 in dl_iterate_phdr () from /lib64/libc.so.6
#7  0x00007ffff7fccd30 in backtrace_initialize
(state=state@entry=0x7ffff7ecc000, descriptor=<optimized out>, 
    error_callback=error_callback@entry=0x7ffff7ee8cd0 <error_callback>,
data=data@entry=0x7fffffffde90, fileline_fn=fileline_fn@entry=0x7fffffffdb08)
    at ../../../gcc/libbacktrace/elf.c:944
#8  0x00007ffff7fcb8b4 in fileline_initialize
(state=state@entry=0x7ffff7ecc000,
error_callback=error_callback@entry=0x7ffff7ee8cd0 <error_callback>, 
    data=data@entry=0x7fffffffde90) at ../../../gcc/libbacktrace/fileline.c:136
#9  0x00007ffff7fcb992 in backtrace_pcinfo (state=0x7ffff7ecc000,
pc=140737352994313, callback=0x7ffff7ee8b10 <full_callback>, 
    error_callback=0x7ffff7ee8cd0 <error_callback>, data=0x7fffffffde90) at
../../../gcc/libbacktrace/fileline.c:170
#10 0x00007ffff7fcbe61 in unwind (context=<optimized out>,
vdata=0x7fffffffde50) at ../../../gcc/libbacktrace/backtrace.c:83
#11 0x00007ffff7ea8439 in _Unwind_Backtrace (trace=trace@entry=0x7ffff7fcbe10
<unwind>, trace_argument=trace_argument@entry=0x7fffffffde50)
    at ../../../gcc/libgcc/unwind.inc:295
#12 0x00007ffff7fcbeb5 in backtrace_full (state=state@entry=0x7ffff7ecc000,
skip=skip@entry=0, callback=callback@entry=0x7ffff7ee8b10 <full_callback>, 
    error_callback=error_callback@entry=0x7ffff7ee8cd0 <error_callback>,
data=data@entry=0x7fffffffde90) at ../../../gcc/libbacktrace/backtrace.c:106
#13 0x00007ffff7ee8e0a in _gfortrani_show_backtrace
(in_signal_handler=in_signal_handler@entry=false) at
../../../gcc/libgfortran/runtime/backtrace.c:156
#14 0x00007ffff7ee9906 in _gfortrani_exit_error (status=status@entry=1) at
../../../gcc/libgfortran/runtime/error.c:196
#15 0x00007ffff7ee9b03 in _gfortrani_os_error (message=0x400a28 "Allocation
would exceed memory limit") at ../../../gcc/libgfortran/runtime/error.c:348
#16 0x000000000040081e in foomod::foo (a=..., n=0) at test_1.f90:7
#17 0x00000000004008c0 in MAIN__ () at test_1.f90:16


Testcase:
> cat test_1.f90
MODULE foomod

CONTAINS
  SUBROUTINE foo(a,N)
   INTEGER, DIMENSION(:), POINTER :: a
   INTEGER :: N
   ALLOCATE(a(N))
   a=0
  END SUBROUTINE
END MODULE foomod

USE foomod
INTEGER, DIMENSION(:), POINTER :: a
INTEGER :: N
DO 
CALL foo(a,N)
ENDDO
END


> gfortran -g test_1.f90
> ulimit -v 1000000
> ./a.out
Operating system error: Cannot allocate memory
Allocation would exceed memory limit

Error termination. Backtrace:

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
Segmentation fault


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug other/67457] segfault in libbacktrace
  2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
@ 2015-09-08 13:49 ` ian at gcc dot gnu.org
  2015-09-08 14:06 ` ian at airs dot com
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: ian at gcc dot gnu.org @ 2015-09-08 13:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

--- Comment #1 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Tue Sep  8 13:49:19 2015
New Revision: 227529

URL: https://gcc.gnu.org/viewcvs?rev=227529&root=gcc&view=rev
Log:
        PR other/67457
        * mmap.c (backtrace_alloc): Correct test for mmap failure.

Modified:
    trunk/libbacktrace/ChangeLog
    trunk/libbacktrace/mmap.c


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug other/67457] segfault in libbacktrace
  2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
  2015-09-08 13:49 ` [Bug other/67457] " ian at gcc dot gnu.org
@ 2015-09-08 14:06 ` ian at airs dot com
  2015-09-08 14:50 ` Joost.VandeVondele at mat dot ethz.ch
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: ian at airs dot com @ 2015-09-08 14:06 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Ian Lance Taylor <ian at airs dot com> ---
I committed a patch so that libbacktrace should no longer segfault when no
memory is available.

If other compilers can print a backtrace when mmap fails, then I think they
must be recording all necessary information in loadable sections.  When no
memory is available we could print a trace of PC addresses, but it would be
very painful to print file/line information.  We could stage the I/O through a
static buffer, but finding the information to print without being able to build
any data structures would be very inefficient.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug other/67457] segfault in libbacktrace
  2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
  2015-09-08 13:49 ` [Bug other/67457] " ian at gcc dot gnu.org
  2015-09-08 14:06 ` ian at airs dot com
@ 2015-09-08 14:50 ` Joost.VandeVondele at mat dot ethz.ch
  2015-09-08 16:46 ` ian at gcc dot gnu.org
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2015-09-08 14:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

--- Comment #3 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Ian Lance Taylor from comment #2)
> If other compilers can print a backtrace when mmap fails, then I think they
> must be recording all necessary information in loadable sections.  When no
> memory is available we could print a trace of PC addresses, but it would be
> very painful to print file/line information.  We could stage the I/O through
> a static buffer, but finding the information to print without being able to
> build any data structures would be very inefficient.

actually, just a trace of PC addresses would be sufficient and useful, it would
allow to get the needed info afterwards nevertheless. This is actually what I
get with the other compiler.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug other/67457] segfault in libbacktrace
  2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
                   ` (3 preceding siblings ...)
  2015-09-08 16:46 ` ian at gcc dot gnu.org
@ 2015-09-08 16:46 ` ian at airs dot com
  2015-09-08 17:16 ` Joost.VandeVondele at mat dot ethz.ch
  2021-08-24 18:58 ` pinskia at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: ian at airs dot com @ 2015-09-08 16:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
I committed a patch that should produce a more graceful fallback when out of
memory.  Please see if it helps your situation.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug other/67457] segfault in libbacktrace
  2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
                   ` (2 preceding siblings ...)
  2015-09-08 14:50 ` Joost.VandeVondele at mat dot ethz.ch
@ 2015-09-08 16:46 ` ian at gcc dot gnu.org
  2015-09-08 16:46 ` ian at airs dot com
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: ian at gcc dot gnu.org @ 2015-09-08 16:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
I committed a patch that should produce a more graceful fallback when out of
memory.  Please see if it helps your situation.

--- Comment #5 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Tue Sep  8 16:46:16 2015
New Revision: 227533

URL: https://gcc.gnu.org/viewcvs?rev=227533&root=gcc&view=rev
Log:
        PR other/67457
        * backtrace.c: #include "internal.h".
        (struct backtrace_data): Add can_alloc field.
        (unwind): If can_alloc is false, don't try to get file/line
        information.
        (backtrace_full): Set can_alloc field in bdata.
        * alloc.c (backtrace_alloc): Don't call error_callback if it is
        NULL.
        * mmap.c (backtrace_alloc): Likewise.
        * internal.h: Update comments for backtrace_alloc and
        backtrace_free.

Modified:
    trunk/libbacktrace/ChangeLog
    trunk/libbacktrace/alloc.c
    trunk/libbacktrace/backtrace.c
    trunk/libbacktrace/internal.h
    trunk/libbacktrace/mmap.c


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug other/67457] segfault in libbacktrace
  2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
                   ` (4 preceding siblings ...)
  2015-09-08 16:46 ` ian at airs dot com
@ 2015-09-08 17:16 ` Joost.VandeVondele at mat dot ethz.ch
  2021-08-24 18:58 ` pinskia at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2015-09-08 17:16 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

--- Comment #6 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Ian Lance Taylor from comment #4)
> I committed a patch that should produce a more graceful fallback when out of
> memory.  Please see if it helps your situation.

Great! Not sure how you managed, but this gives a clean symbolic backtrace, at
least for this simple test case:

> ./a.out
Operating system error: Cannot allocate memory
Allocation would exceed memory limit

Error termination. Backtrace:

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory

Could not print backtrace: mmap: Cannot allocate memory
#0  0x7f068c128e09 in ???
#1  0x7f068c129905 in ???
#2  0x7f068c129b02 in ???
#3  0x40081d in __foomod_MOD_foo
        at /data/vjoost/gnu/bugs/test_1.f90:7
#4  0x4008bf in MAIN__
        at /data/vjoost/gnu/bugs/test_1.f90:16
#5  0x4008f5 in main
        at /data/vjoost/gnu/bugs/test_1.f90:12


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug other/67457] segfault in libbacktrace
  2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
                   ` (5 preceding siblings ...)
  2015-09-08 17:16 ` Joost.VandeVondele at mat dot ethz.ch
@ 2021-08-24 18:58 ` pinskia at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-24 18:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobias at stoeckmann dot org

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 67392 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-08-24 18:58 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-05  7:22 [Bug other/67457] New: segfault in libbacktrace Joost.VandeVondele at mat dot ethz.ch
2015-09-08 13:49 ` [Bug other/67457] " ian at gcc dot gnu.org
2015-09-08 14:06 ` ian at airs dot com
2015-09-08 14:50 ` Joost.VandeVondele at mat dot ethz.ch
2015-09-08 16:46 ` ian at gcc dot gnu.org
2015-09-08 16:46 ` ian at airs dot com
2015-09-08 17:16 ` Joost.VandeVondele at mat dot ethz.ch
2021-08-24 18:58 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).