From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2F73A3857708; Tue, 11 Apr 2023 09:02:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F73A3857708 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681203740; bh=xNEZPwrU9DLq1Cln8Qzs6ch7ftluG1XWOpdR6VXB2u8=; h=From:To:Subject:Date:From; b=QH/WhvuhvDbENbI+6g9R79e/2yf06QQoCP1pGVBhV47+7ksQaEhbUr09dLglw6OVG G4k2L+cHmGRNplai0YHnClYT4QcTnj8/yAMhuJUpwR0QeJ7gohK6RkB+KiY1p1cBhK SgLPcCFNA+1auiZD4N3jMrK5Sw6oxk20WWZHIJ24= From: "jg at jguk dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/30331] New: bad dump params gives "virtual memory exhausted" Date: Tue, 11 Apr 2023 09:02:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jg at jguk dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30331 Bug ID: 30331 Summary: bad dump params gives "virtual memory exhausted" Product: gdb Version: 12.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: jg at jguk dot org Target Milestone: --- Kind of similar to this other issue bug 20373 Is there a way to detect bad parameters when dumping memory to avoid gdb co= re dump? otherwise it punishes clueless programmers Would be good if when we define macros and run them, they don't give Y answ= ers for the later gdb core dump NB. "----- Backtrace -----" addresses don't seem to match the gdb core file= it dumped. Just an example. int main() { char * a =3D 0x0; *a =3D 1; } $ gdb -c crash2_S11_1681076589.core GNU gdb (Ubuntu 12.1-3ubuntu2) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". [New LWP 830133] This GDB supports auto-downloading debuginfo from the following URLs: https://debuginfod.ubuntu.com=20 Enable debuginfod for this session? (y or [n]) n Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbini= t. Core was generated by `./crash2'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000562e40e0b13d in ?? () (gdb) define mem_dump Type commands for definition of "mem_dump". End with a line saying just "end". > dump binary memory dump.bin $arg0 $arg0+$arg1 > end (gdb) mem_dump 100 0x0000562e40e0b13d /build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:712: internal-error: virtual memory exhausted: can't allocate 94756656951613 bytes. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x559d96041fb6 ??? 0x559d963a08b4 ??? 0x559d963a0af0 ??? 0x559d964efef4 ??? 0x559d9639be91 ??? 0x559d964f3c4a ??? 0x559d9607b044 ??? 0x559d96077714 ??? 0x559d963611ef ??? 0x559d96083bb2 ??? 0x559d96083ff9 ??? 0x559d96084365 ??? 0x559d9636104d ??? 0x559d96141c64 ??? 0x559d96141ff0 ??? 0x559d961426a2 ??? 0x7f306352374c ??? 0x559d961427fd ??? 0x559d961429b3 ??? 0x559d96140b4c ??? 0x559d964f04a5 ??? 0x559d964f0a66 ??? 0x559d961fb66c ??? 0x559d961fd3a4 ??? 0x559d95fa49bd ??? 0x7f306222350f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f30622235c8 __libc_start_main_impl ../csu/libc-start.c:381 0x559d95faa524 ??? 0xffffffffffffffff ??? --------------------- /build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:712: internal-error: virtual memory exhausted: can't allocate 94756656951613 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: . /build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:712: internal-error: virtual memory exhausted: can't allocate 94756656951613 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) Core was generated by `gdb -c crash2_S11_1681076589.core'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (no_tid=3D0, signo=3D6, threadid=3D) at ./nptl/pthread_kill.c:44 Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c. 44 ./nptl/pthread_kill.c: No such file or directory. [Current thread is 1 (Thread 0x7f26e710a180 (LWP 561671))] (gdb) bt #0 __pthread_kill_implementation (no_tid=3D0, signo=3D6, threadid=3D) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=3D6, threadid=3D) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=3D, signo=3Dsigno@entry=3D= 6) at ./nptl/pthread_kill.c:89 #3 0x00007f26e7c3bc46 in __GI_raise (sig=3Dsig@entry=3D6) at ../sysdeps/posix/raise.c:26 #4 0x00007f26e7c227fc in __GI_abort () at ./stdlib/abort.c:79 #5 0x0000564e59362c1e in dump_core () at /build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:211 #6 0x0000564e59367806 in internal_vproblem(internal_problem *, const char = *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=3D, file=3D, line=3D, fmt=3D, ap=3D) at /build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:455 #7 0x0000564e59367af1 in internal_verror (file=3D, line=3D, fmt=3D, ap=3Dap@entry=3D0x7ffe4be29c= e0) at /build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:471 #8 0x0000564e594b6ef5 in internal_error (file=3Dfile@entry=3D0x564e595e2250 "/build/gdb-hsz3w3/gdb-12.1/gdb/utils.c", line=3Dline@entry=3D712, fmt=3D) at /build/gdb-hsz3w3/gdb-12.1/gdbsupport/errors.cc:55 #9 0x0000564e59362e92 in malloc_failure (size=3Dsize@entry=3D9475665695161= 3) at /build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:712 #10 0x0000564e594bac4b in operator new (sz=3Dsz@entry=3D94756656951613) at /build/gdb-hsz3w3/gdb-12.1/gdbsupport/new-op.cc:70 #11 0x0000564e59042045 in std::__new_allocator::allocate (__n=3D94756656951613, this=3D) at /usr/include/c++/12/bits/new_allocator.h:112 #12 std::allocator_traits > >::allocate (__n=3D94756656951613, __a=3D..= .) at /usr/include/c++/12/bits/alloc_traits.h:318 #13 std::_Vector_base > >::_M_allocate (this=3D0x7ffe4be29e00, __n=3D94756656951613) at /usr/include/c++/12/bits/stl_vector.h:378 #14 std::_Vector_base > >::_M_create_storage (__n=3D94756656951613, this=3D0x7ffe4be29e00) at /usr/include/c++/12/bits/stl_vector.h:395 #15 std::_Vector_base > >::_Vector_base (__a=3D..., __n=3D947566569= 51613, this=3D0x7ffe4be29e00) at /usr/include/c++/12/bits/stl_vector.h:332 #16 std::vector > >::vector (__a=3D..., __n=3D94756656951613, this=3D0x7ffe4be29e00) at /usr/include/c++/12/bits/stl_vector.h:552 #17 dump_memory_to_file (cmd=3D, mode=3D0x564e595501e5 "wb", file_format=3D0x564e595bc199 "binary") at /build/gdb-hsz3w3/gdb-12.1/gdb/cli/cli-dump.c:194 #18 0x0000564e5903e715 in cmd_func (cmd=3D, args=3D, from_tty=3D) at /build/gdb-hsz3w3/gdb-12.1/gdb/cli/cli-decode.c:2514 #19 0x0000564e593281f0 in execute_command (p=3D, from_tty=3Dfrom_tty@entry=3D0) at /build/gdb-hsz3w3/gdb-12.1/gdb/top.c:702 #20 0x0000564e5904abb3 in execute_control_command_1 (cmd=3D0x564e5b3c6aa0, from_tty=3D0) at /usr/include/c++/12/bits/basic_string.h:233 #21 0x0000564e5904affa in execute_control_commands (cmdlines=3D0x564e5b3c6a= a0, from_tty=3D0) at /build/gdb-hsz3w3/gdb-12.1/gdb/cli/cli-script.c:410 #22 0x0000564e5904b366 in execute_user_command (c=3Dc@entry=3D0x564e5b19f63= 0, args=3Dargs@entry=3D0x564e5b19f829 "100 0x0000562e40e0b13d") at /build/gdb-hsz3w3/gdb-12.1/gdb/cli/cli-script.c:460 #23 0x0000564e5932804e in execute_command (p=3D, p@entry=3D0x564e5b19f820 "mem_dump 100 0x0000562e40e0b13d", from_tty=3D1) at /build/gdb-hsz3w3/gdb-12.1/gdb/top.c:676 #24 0x0000564e59108c65 in command_handler (command=3D0x564e5b19f820 "mem_du= mp 100 0x0000562e40e0b13d") at /build/gdb-hsz3w3/gdb-12.1/gdb/event-top.c:597 #25 0x0000564e59108ff1 in command_line_handler (rl=3D...) at /build/gdb-hsz3w3/gdb-12.1/gdb/event-top.c:800 #26 0x0000564e591096a3 in gdb_rl_callback_handler (rl=3D0x564e5b3c6900 "mem= _dump 100 0x0000562e40e0b13d") at /build/gdb-hsz3w3/gdb-12.1/gdb/event-top.c:229 #27 0x00007f26e90f574d in rl_callback_read_char () from /lib/x86_64-linux-gnu/libreadline.so.8 #28 0x0000564e591097fe in gdb_rl_callback_read_char_wrapper_noexcept () at /build/gdb-hsz3w3/gdb-12.1/gdb/event-top.c:187 #29 0x0000564e591099b4 in gdb_rl_callback_read_char_wrapper (client_data=3D) at /build/gdb-hsz3w3/gdb-12.1/gdb/event-top= .c:204 #30 0x0000564e59107b4d in stdin_event_handler (error=3D, client_data=3D0x564e5b19d950) at /build/gdb-hsz3w3/gdb-12.1/gdb/event-top.c= :524 #31 0x0000564e594b74a6 in gdb_wait_for_event (block=3Dblock@entry=3D1) at /build/gdb-hsz3w3/gdb-12.1/gdbsupport/event-loop.cc:725 #32 0x0000564e594b7a67 in gdb_do_one_event () at /build/gdb-hsz3w3/gdb-12.1/gdbsupport/event-loop.cc:237 #33 0x0000564e591c266d in start_event_loop () at /build/gdb-hsz3w3/gdb-12.1/gdb/main.c:421 #34 captured_command_loop () at /build/gdb-hsz3w3/gdb-12.1/gdb/main.c:481 #35 0x0000564e591c43a5 in captured_main (data=3D0x7ffe4be2a430) at /build/gdb-hsz3w3/gdb-12.1/gdb/main.c:1351 #36 gdb_main (args=3Dargs@entry=3D0x7ffe4be2a460) at /build/gdb-hsz3w3/gdb-12.1/gdb/main.c:1366 #37 0x0000564e58f6b9be in main (argc=3D, argv=3D) at /build/gdb-hsz3w3/gdb-12.1/gdb/gdb.c:32 --=20 You are receiving this mail because: You are on the CC list for the bug.=