[Bug breakpoints/29960] New: gdb doesn't prevent user from setting faulty catch condition and segfaults

[Bug breakpoints/29960] New: gdb doesn't prevent user from setting faulty catch condition and segfaults

[festerdam at posteo dot net]

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.

[Bug breakpoints/29960] gdb doesn't prevent user from setting faulty catch condition and segfaults

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |tromey at sourceware dot org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-01-04

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Was able to reproduce.

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

[Bug breakpoints/29960] gdb doesn't prevent user from setting faulty catch condition and segfaults

[tromey at sourceware dot org]

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

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
I think the problem is that re-running does not end up reparsing
the breakpoint condition on the catch.  i.e., a bug in the
breakpoint refactoring.

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

[Bug breakpoints/29960] gdb doesn't prevent user from setting faulty catch condition and segfaults

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
I was able to reproduce this as far back as 835e063d3a0, 
which is before the breakpoint changes I was thinking of.

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