public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "festerdam at posteo dot net" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug breakpoints/29960] New: gdb doesn't prevent user from setting faulty catch condition and segfaults Date: Tue, 03 Jan 2023 18:23:38 +0000 [thread overview] Message-ID: <bug-29960-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29960 Bug ID: 29960 Summary: gdb doesn't prevent user from setting faulty catch condition and segfaults Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: breakpoints Assignee: unassigned at sourceware dot org Reporter: festerdam at posteo dot net Target Milestone: --- When inputting the following to gdb: r # Let child exit normally catch syscall 1 condition 1 fd == 1 #assume catchpoint obtained above is 1 # Will fail saying that no symbol table is loaded or that the symbol doesn't # exist. Outcome in the end will be the same condition 1 write.fd == 1 # won't fail for some reason r # segfault occurs now It seems I always have to run the program prior to setting the syscall in order for this to happen. I tested it with GNU Hello, GNU Bash and GNU Guile and with gdb version 12.1-4 (obtained from the Debian repositories) and with gdb commit ce6fcad80eb594228a2e46e9362d6083881fe96d. They all crashed. This is the stack trace of spat out by gdb ce6fcad80 running GNU Hello: Fatal signal: Segmentation fault ----- Backtrace ----- 0x55555570204b gdb_internal_backtrace_1 ../../gdb/bt-utils.c:122 0x55555570204b _Z22gdb_internal_backtracev ../../gdb/bt-utils.c:168 0x555555813421 handle_fatal_signal ../../gdb/event-top.c:956 0x55555581358c handle_sigsegv ../../gdb/event-top.c:1029 0x7ffff6e5af8f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x555555a35a90 _ZNK19general_symbol_info13section_indexEv ../../gdb/symtab.h:605 0x555555a35a90 _ZNK19general_symbol_info11obj_sectionEPK7objfile ../../gdb/symtab.c:1090 0x555555952139 _Z28find_minsym_type_and_addressP14minimal_symbolP7objfilePm ../../gdb/parse.c:105 0x55555580e373 _Z23evaluate_var_msym_value6nosideP7objfileP14minimal_symbol ../../gdb/eval.c:597 0x55555580e89e _Z22eval_op_var_msym_valueP4typeP10expression6nosideb20bound_minimal_symbol ../../gdb/eval.c:1113 0x555555716e10 _ZN4expr18structop_operation8evaluateEP4typeP10expression6noside ../../gdb/expop.h:1034 0x555555716d14 _ZN4expr20comparison_operationIL10exp_opcode14EXadL_Z13eval_op_equalP4typeP10expression6nosideS1_P5valueS8_EEE8evaluateES3_S5_S6_ ../../gdb/expop.h:1334 0x55555580d55c _ZN10expression8evaluateEP4type6noside ../../gdb/eval.c:101 0x5555556eddb1 breakpoint_cond_eval ../../gdb/breakpoint.c:4971 0x5555556eddb1 bpstat_check_breakpoint_conditions ../../gdb/breakpoint.c:5540 0x5555556f6616 _Z18bpstat_stop_statusPK13address_spacemP11thread_infoRK17target_waitstatusP6bpstat ../../gdb/breakpoint.c:5721 0x5555558b5985 handle_syscall_event ../../gdb/infrun.c:4625 0x5555558b5eb7 handle_inferior_event ../../gdb/infrun.c:5832 0x5555558b82fe _Z20fetch_inferior_eventv ../../gdb/infrun.c:4202 0x555555c286d5 gdb_wait_for_event ../../gdbsupport/event-loop.cc:716 0x555555c291b2 _Z16gdb_do_one_eventi ../../gdbsupport/event-loop.cc:264 0x5555558fb609 start_event_loop ../../gdb/main.c:411 0x5555558fb609 captured_command_loop ../../gdb/main.c:471 0x5555558fd164 captured_main ../../gdb/main.c:1310 0x5555558fd164 _Z8gdb_mainP18captured_main_args ../../gdb/main.c:1325 0x5555556614a9 main ../../gdb/gdb.c:32 And this is the stack trace I get when I run gdb with gdb (not sure why they are different): #0 general_symbol_info::obj_section (this=this@entry=0x7fffee85f4e0, objfile=objfile@entry=0x5555561fdf80) at ../../gdb/symtab.c:1090 #1 0x000055555595213a in find_minsym_type_and_address (msymbol=0x7fffee85f4e0, objfile=0x5555561fdf80, address_p=address_p@entry=0x7fffffffd5d8) at ../../gdb/parse.c:105 #2 0x000055555580e374 in evaluate_var_msym_value (noside=noside@entry=EVAL_NORMAL, objfile=<optimized out>, msymbol=<optimized out>) at ../../gdb/eval.c:597 #3 0x000055555580e89f in eval_op_var_msym_value (expect_type=<optimized out>, exp=<optimized out>, noside=EVAL_NORMAL, outermost_p=<optimized out>, msymbol=...) at ../../gdb/eval.c:1113 #4 0x0000555555716e11 in expr::structop_operation::evaluate (this=0x55555626d2c0, expect_type=0x0, exp=0x55555623fa20, noside=EVAL_NORMAL) at ../../gdb/expop.h:1034 #5 0x0000555555716d15 in expr::comparison_operation<(exp_opcode)14, &(eval_op_equal(type*, expression*, noside, exp_opcode, value*, value*))>::evaluate (this=0x55555623fa40, expect_type=0x0, exp=0x55555623fa20, noside=EVAL_NORMAL) at ../../gdb/expop.h:1334 #6 0x000055555580d55d in expression::evaluate (this=0x55555623fa20, expect_type=0x0, noside=EVAL_NORMAL) at ../../gdb/eval.c:101 #7 0x00005555556eddb2 in breakpoint_cond_eval (exp=0x55555623fa20) at ../../gdb/breakpoint.c:4971 #8 bpstat_check_breakpoint_conditions (bs=<optimized out>, thread=0x5555561b8800) at ../../gdb/breakpoint.c:5540 #9 0x00005555556f6617 in bpstat_stop_status (aspace=<optimized out>, bp_addr=<optimized out>, thread=0x5555561b8800, ws=..., stop_chain=<optimized out>) at ../../gdb/breakpoint.c:5721 #10 0x00005555558b5986 in handle_syscall_event (ecs=ecs@entry=0x7fffffffdd80) at ../../gdb/regcache.h:344 #11 0x00005555558b5eb8 in handle_inferior_event (ecs=0x7fffffffdd80) at ../../gdb/infrun.c:5832 --Type <RET> for more, q to quit, c to continue without paging--c #12 0x00005555558b82ff in fetch_inferior_event () at ../../gdb/infrun.c:4202 #13 0x0000555555c286d6 in gdb_wait_for_event (block=block@entry=1) at ../../gdbsupport/event-loop.cc:716 #14 0x0000555555c291b3 in gdb_do_one_event (mstimeout=mstimeout@entry=-1) at ../../gdbsupport/event-loop.cc:264 #15 0x00005555558fb60a in start_event_loop () at ../../gdb/main.c:411 #16 captured_command_loop () at ../../gdb/main.c:471 #17 0x00005555558fd165 in captured_main (data=data@entry=0x7fffffffded0) at ../../gdb/main.c:1310 #18 gdb_main (args=args@entry=0x7fffffffdf00) at ../../gdb/main.c:1325 #19 0x00005555556614aa in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:32 I have a coredump, if needed. It was too big to attach. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2023-01-03 18:23 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-03 18:23 festerdam at posteo dot net [this message] 2023-01-04 2:09 ` [Bug breakpoints/29960] " tromey at sourceware dot org 2023-01-04 23:42 ` tromey at sourceware dot org 2023-01-05 23:41 ` tromey at sourceware dot org 2024-09-04 14:30 ` cvs-commit at gcc dot gnu.org 2024-09-04 14:33 ` aburgess at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29960-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).