[Bug record/20456] New: gdb crash with record and d

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] New: gdb crash with record and d

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

            Bug ID: 20456
           Summary: gdb crash with record and d
           Product: gdb
           Version: 7.11
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: record
          Assignee: unassigned at sourceware dot org
          Reporter: 13nixonf at gmail dot com
  Target Milestone: ---

While debugging a gtk application in d, I got the following:

Thread 1 "my-ide" hit Breakpoint 1,
main_ui.FileViewer.this(gtk.Builder.Builder).recurseOverDirectories(gtk.TreeStore.TreeStore,
gtk.TreeIter.TreeIter, immutable(char)[]) (this=0x7ffff7ed0800, path=...,
parent=0x0, store=0x7ffff7ecb100) at source/main_ui.d:69
69                                      TreeIter iter = store.append(parent);
(gdb) record
(gdb) c
Continuing.
/build/gdb-GtCqbH/gdb-7.11.1/gdb/nat/x86-linux-dregs.c:146: internal-error:
x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

/build/gdb-GtCqbH/gdb-7.11.1/gdb/nat/x86-linux-dregs.c:146: internal-error:
x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Command aborted.
(gdb) /build/gdb-GtCqbH/gdb-7.11.1/gdb/nat/x86-linux-dregs.c:146:
internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped
(lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

/build/gdb-GtCqbH/gdb-7.11.1/gdb/nat/x86-linux-dregs.c:146: internal-error:
x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Command aborted.
(gdb) [Thread 0x7fffd37fe700 (LWP 25530) exited]
/build/gdb-GtCqbH/gdb-7.11.1/gdb/nat/x86-linux-dregs.c:146: internal-error:
x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

/build/gdb-GtCqbH/gdb-7.11.1/gdb/nat/x86-linux-dregs.c:146: internal-error:
x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Aborted (core dumped)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
Any chance you could try gdb's master and gdb-7.12-branch branches?

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

--- Comment #2 from 13nixonf at gmail dot com ---
Working on  switching to gdb-7.12, meanwhile here's the core dump:
https://drive.google.com/file/d/0B7tlyGGxBlMtUFFEeXRMVGlkN3c/view?usp=sharing

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

--- Comment #3 from 13nixonf at gmail dot com ---
same error on 7.12.50.20160810-git:



Thread 1 "my-ide" hit Breakpoint 1,
main_ui.FileViewer.this(gtk.Builder.Builder).recurseOverDirectories(gtk.TreeStore.TreeStore,
gtk.TreeIter.TreeIter, immutable(char)[]) (this=0x7ffff7ed2800, path=...,
parent=0x0, store=0x7ffff7ecd100) at source/main_ui.d:69
69                                      TreeIter iter = store.append(parent);
(gdb) record
(gdb) c
Continuing.
Couldn't get registers: No such process.
(gdb) ./nat/x86-linux-dregs.c:146: internal-error: void
x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
Ideally we'd have some way to reproduce this.

What did you do before "record"?  Did you set any watchpoint?  Does the program
spawn threads?

A gdb session with with:

 set debug infrun 1
 set debug lin-lwp 1
 set debug record 1

might shed some light.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

--- Comment #5 from 13nixonf at gmail dot com ---
(In reply to Pedro Alves from comment #4)

> Ideally we'd have some way to reproduce this.
>
> What did you do before "record"?  Did you set any watchpoint?  Does the
> program spawn threads?
>
> A gdb session with with:
>
>  set debug infrun 1
>  set debug lin-lwp 1
>  set debug record 1
>
> might shed some light.

I set one breakpoint. I did "record" once I hit the breakpoint. The program
does spawn threads.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

--- Comment #6 from 13nixonf at gmail dot com ---
Here's the output with:
 set debug infrun 1
 set debug lin-lwp 1
 set debug record 1


Thread 1 "my-ide" hit Breakpoint 1,
main_ui.FileViewer.this(gtk.Builder.Builder).recurseOverDirectories(gtk.TreeStore.TreeStore,
gtk.TreeIter.TreeIter, immutable(char)[]) (this=0x7ffff7ed2800, path=...,
parent=0x0, store=0x7ffff7ecd100)
    at source/main_ui.d:66
66                              }
(gdb) set debug infrun 1
(gdb) set debug lin-lwp 1
(gdb) set debug record 1
(gdb) record
Process record: record_full_open
Process record: record_full_open
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcd940 (LWP 7693))
infrun: clear_proceed_status_thread (Thread 0x7fffeceff700 (LWP 7694))
infrun: clear_proceed_status_thread (Thread 0x7fffec6fe700 (LWP 7695))
infrun: clear_proceed_status_thread (Thread 0x7fffea5c6700 (LWP 7701))
infrun: clear_proceed_status_thread (Thread 0x7fffe8d16700 (LWP 7705))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 0x7ffff7fcd940 (LWP 7693)] for step-over
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun:   Thread 0x7ffff7fcd940 (LWP 7693) not executing
infrun:   Thread 0x7fffeceff700 (LWP 7694) not executing
infrun:   Thread 0x7fffec6fe700 (LWP 7695) not executing
infrun:   Thread 0x7fffea5c6700 (LWP 7701) not executing
infrun:   Thread 0x7fffe8d16700 (LWP 7705) not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun:   Thread 0x7ffff7fcd940 (LWP 7693) not executing
infrun:   Thread 0x7fffeceff700 (LWP 7694) not executing
infrun:   Thread 0x7fffec6fe700 (LWP 7695) not executing
infrun:   Thread 0x7fffea5c6700 (LWP 7701) not executing
infrun:   Thread 0x7fffe8d16700 (LWP 7705) not executing
infrun: stop_all_threads done
infrun: skipping breakpoint: stepping past insn at: 0x7546e5
infrun: skipping breakpoint: stepping past insn at: 0x7546e5
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread
[Thread 0x7ffff7fcd940 (LWP 7693)] at 0x7546e5
LLR: Preparing to step Thread 0x7ffff7fcd940 (LWP 7693), 0, inferior_ptid
Thread 0x7ffff7fcd940 (LWP 7693)
LLR: PTRACE_SINGLESTEP Thread 0x7ffff7fcd940 (LWP 7693), 0 (resume event
thread)
infrun: infrun_async(1)
sigchld
infrun: prepare_to_wait
Process record: record_full_wait record_full_resume_step = 1,
record_full_resumed = 1, direction=forward
linux_nat_wait: [process -1], [TARGET_WNOHANG]
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), not resumed
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not resumed
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), not resumed
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), not resumed
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), not stopped
LLW: enter
LNW: waitpid(-1, ...) returned 7693, ERRNO-OK
LLW: waitpid 7693 received Trace/breakpoint trap (stopped)
CSBB: Thread 0x7ffff7fcd940 (LWP 7693) stopped by trace
LNW: waitpid(-1, ...) returned 0, ERRNO-OK
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), not resumed
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not resumed
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), not resumed
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), not resumed
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), has pending status
LLW: trap ptid is Thread 0x7ffff7fcd940 (LWP 7693).
LLW: exit
infrun: target_wait (-1.0.0, status) =
infrun:   7693.7693.0 [Thread 0x7ffff7fcd940 (LWP 7693)],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: clear_step_over_info
infrun: restart threads: [Thread 0x7ffff7fcd940 (LWP 7693)] is event thread
infrun: restart threads: [Thread 0x7fffeceff700 (LWP 7694)] continuing
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread 0x7fffeceff700 (LWP 7694)] at 0x7ffff6fd219d
LLR: Preparing to step Thread 0x7fffeceff700 (LWP 7694), 0, inferior_ptid
Thread 0x7fffeceff700 (LWP 7694)
LLR: PTRACE_SINGLESTEP Thread 0x7fffeceff700 (LWP 7694), 0 (resume event
thread)
infrun: prepare_to_wait
infrun: restart threads: [Thread 0x7fffec6fe700 (LWP 7695)] continuing
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread 0x7fffec6fe700 (LWP 7695)] at 0x7ffff6fd219d
LLR: Preparing to step Thread 0x7fffec6fe700 (LWP 7695), 0, inferior_ptid
Thread 0x7fffec6fe700 (LWP 7695)
LLR: PTRACE_SINGLESTEP Thread 0x7fffec6fe700 (LWP 7695), 0 (resume event
thread)
infrun: prepare_to_wait
infrun: restart threads: [Thread 0x7fffea5c6700 (LWP 7701)] continuing
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread 0x7fffea5c6700 (LWP 7701)] at 0x7ffff6fd219d
LLR: Preparing to step Thread 0x7fffea5c6700 (LWP 7701), 0, inferior_ptid
Thread 0x7fffea5c6700 (LWP 7701)
LLR: PTRACE_SINGLESTEP Thread 0x7fffea5c6700 (LWP 7701), 0 (resume event
thread)
infrun: prepare_to_wait
infrun: restart threads: [Thread 0x7fffe8d16700 (LWP 7705)] continuing
sigchld
sigchld
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread 0x7fffe8d16700 (LWP 7705)] at 0x7ffff6fd6e49
LLR: Preparing to step Thread 0x7fffe8d16700 (LWP 7705), 0, inferior_ptid
Thread 0x7fffe8d16700 (LWP 7705)
LLR: PTRACE_SINGLESTEP Thread 0x7fffe8d16700 (LWP 7705), 0 (resume event
thread)
infrun: prepare_to_wait
infrun: stop_pc = 0x7546ec
infrun: context switch
infrun: Switching context from Thread 0x7fffe8d16700 (LWP 7705) to Thread
0x7ffff7fcd940 (LWP 7693)
sigchld
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[Thread 0x7ffff7fcd940 (LWP 7693)] at 0x7546ec
LLR: Preparing to step Thread 0x7ffff7fcd940 (LWP 7693), 0, inferior_ptid
Thread 0x7ffff7fcd940 (LWP 7693)
LLR: PTRACE_SINGLESTEP Thread 0x7ffff7fcd940 (LWP 7693), 0 (resume event
thread)
infrun: prepare_to_wait
Process record: record_full_wait record_full_resume_step = 0,
record_full_resumed = 1, direction=forward
linux_nat_wait: [process -1], [TARGET_WNOHANG]
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), not stopped
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), not stopped
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), not stopped
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), not stopped
LLW: enter
LNW: waitpid(-1, ...) returned 7705, ERRNO-OK
LLW: waitpid 7705 received Trace/breakpoint trap (stopped)
LNW: waitpid(-1, ...) returned 7693, ERRNO-OK
LLW: waitpid 7693 received Trace/breakpoint trap (stopped)
CSBB: Thread 0x7ffff7fcd940 (LWP 7693) stopped by trace
LNW: waitpid(-1, ...) returned 7695, ERRNO-OK
LLW: waitpid 7695 received Trace/breakpoint trap (stopped)
LNW: waitpid(-1, ...) returned 7694, ERRNO-OK
LLW: waitpid 7694 received Trace/breakpoint trap (stopped)
LNW: waitpid(-1, ...) returned 0, ERRNO-OK
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), has pending status
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), has pending status
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), has pending status
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), has pending status
SEL: Found 4 events, selecting #0
LLW: trap ptid is Thread 0x7fffe8d16700 (LWP 7705).
LLW: exit
sigchld
Process record: record_full_wait issuing one more step in the target beneath
LLR: Preparing to step process -1, 0, inferior_ptid Thread 0x7ffff7fcd940 (LWP
7693)
LLR: Short circuiting for status 0x57f
linux_nat_wait: [process -1], [TARGET_WNOHANG]
RSRL: resuming stopped-resumed LWP Thread 0x7fffe8d16700 (LWP 7705) at
0x7ffff6fd6e49: step=1
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), has pending status
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), has pending status
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), has pending status
LLW: enter
LLW: Using pending wait status Trace/breakpoint trap (stopped) for Thread
0x7fffec6fe700 (LWP 7695).
SEL: Found 3 events, selecting #1
LLW: trap ptid is Thread 0x7fffeceff700 (LWP 7694).
LLW: exit
sigchld
Process record: record_full_wait issuing one more step in the target beneath
LLR: Preparing to step process -1, 0, inferior_ptid Thread 0x7ffff7fcd940 (LWP
7693)
LLR: Short circuiting for status 0x57f
linux_nat_wait: [process -1], [TARGET_WNOHANG]
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), not stopped
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), has pending status
RSRL: resuming stopped-resumed LWP Thread 0x7fffeceff700 (LWP 7694) at
0x7ffff6fd219d: step=1
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), has pending status
LLW: enter
LLW: Using pending wait status Trace/breakpoint trap (stopped) for Thread
0x7fffec6fe700 (LWP 7695).
SEL: Found 2 events, selecting #0
LLW: trap ptid is Thread 0x7fffec6fe700 (LWP 7695).
LLW: exit
sigchld
Process record: record_full_wait issuing one more step in the target beneath
LLR: Preparing to step process -1, 0, inferior_ptid Thread 0x7ffff7fcd940 (LWP
7693)
LLR: Short circuiting for status 0x57f
linux_nat_wait: [process -1], [TARGET_WNOHANG]
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), not stopped
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: resuming stopped-resumed LWP Thread 0x7fffec6fe700 (LWP 7695) at
0x7ffff6fd219d: step=1
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), not stopped
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), has pending status
LLW: enter
LLW: Using pending wait status Trace/breakpoint trap (stopped) for Thread
0x7ffff7fcd940 (LWP 7693).
LLW: trap ptid is Thread 0x7ffff7fcd940 (LWP 7693).
LLW: exit
sigchld
Process record: record_full_wait issuing one more step in the target beneath
LLR: Preparing to step process -1, 0, inferior_ptid Thread 0x7ffff7fcd940 (LWP
7693)
RC: Not resuming sibling Thread 0x7fffe8d16700 (LWP 7705) (not stopped)
RC: Not resuming sibling Thread 0x7fffea5c6700 (LWP 7701) (not stopped)
RC: Not resuming sibling Thread 0x7fffec6fe700 (LWP 7695) (not stopped)
RC: Not resuming sibling Thread 0x7fffeceff700 (LWP 7694) (not stopped)
LLR: PTRACE_SINGLESTEP Thread 0x7ffff7fcd940 (LWP 7693), 0 (resume event
thread)
linux_nat_wait: [process -1], [TARGET_WNOHANG]
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), not stopped
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), not stopped
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), not stopped
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), not stopped
LLW: enter
LNW: waitpid(-1, ...) returned 7705, ERRNO-OK
LLW: waitpid 7705 received Trace/breakpoint trap (stopped)
CSBB: Thread 0x7fffe8d16700 (LWP 7705) stopped by trace
LNW: waitpid(-1, ...) returned 7693, ERRNO-OK
LLW: waitpid 7693 received Trace/breakpoint trap (stopped)
CSBB: Thread 0x7ffff7fcd940 (LWP 7693) stopped by trace
LNW: waitpid(-1, ...) returned 7695, ERRNO-OK
LLW: waitpid 7695 received Trace/breakpoint trap (stopped)
CSBB: Thread 0x7fffec6fe700 (LWP 7695) stopped by trace
LNW: waitpid(-1, ...) returned 7694, ERRNO-OK
LLW: waitpid 7694 received Trace/breakpoint trap (stopped)
CSBB: Thread 0x7fffeceff700 (LWP 7694) stopped by trace
LNW: waitpid(-1, ...) returned 0, ERRNO-OK
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), has pending status
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), has pending status
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), has pending status
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), has pending status
SEL: Found 4 events, selecting #3
LLW: trap ptid is Thread 0x7ffff7fcd940 (LWP 7693).
LLW: exit
sigchld
Process record: record_full_wait issuing one more step in the target beneath
LLR: Preparing to step process -1, 0, inferior_ptid Thread 0x7ffff7fcd940 (LWP
7693)
RC: Not resuming sibling Thread 0x7fffe8d16700 (LWP 7705) (has pending)
RC: Not resuming sibling Thread 0x7fffea5c6700 (LWP 7701) (not stopped)
RC: Not resuming sibling Thread 0x7fffec6fe700 (LWP 7695) (has pending)
RC: Not resuming sibling Thread 0x7fffeceff700 (LWP 7694) (has pending)
LLR: PTRACE_SINGLESTEP Thread 0x7ffff7fcd940 (LWP 7693), 0 (resume event
thread)
linux_nat_wait: [process -1], [TARGET_WNOHANG]
RSRL: NOT resuming LWP Thread 0x7fffe8d16700 (LWP 7705), has pending status
RSRL: NOT resuming LWP Thread 0x7fffea5c6700 (LWP 7701), not stopped
RSRL: NOT resuming LWP Thread 0x7fffec6fe700 (LWP 7695), has pending status
RSRL: NOT resuming LWP Thread 0x7fffeceff700 (LWP 7694), has pending status
RSRL: NOT resuming LWP Thread 0x7ffff7fcd940 (LWP 7693), not stopped
LLW: enter
LLW: Using pending wait status Trace/breakpoint trap (stopped) for Thread
0x7fffe8d16700 (LWP 7705).
SEL: Found 3 events, selecting #2
LLW: trap ptid is Thread 0x7fffeceff700 (LWP 7694).
LLW: exit
sigchld
Process record: record_full_wait issuing one more step in the target beneath
LLR: Preparing to step process -1, 0, inferior_ptid Thread 0x7ffff7fcd940 (LWP
7693)
RC: Not resuming sibling Thread 0x7fffe8d16700 (LWP 7705) (has pending)
RC: Not resuming sibling Thread 0x7fffea5c6700 (LWP 7701) (not stopped)
RC: Not resuming sibling Thread 0x7fffec6fe700 (LWP 7695) (has pending)
RC: Resuming sibling Thread 0x7fffeceff700 (LWP 7694), 0, resume
LLR: PTRACE_SINGLESTEP Thread 0x7ffff7fcd940 (LWP 7693), 0 (resume event
thread)
infrun: infrun_async(0)
./nat/x86-linux-dregs.c:146: internal-error: void
x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

Dmitry G. Djachenko <dimhen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dimhen at gmail dot com

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

Bernhard Übelacker <bernhardu at mailbox dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernhardu at mailbox dot org

--- Comment #7 from Bernhard Übelacker <bernhardu at mailbox dot org> ---
I tried to debug in a debian buster amd64 qemu VM the application kalgebra.

There I received that message too:
    (gdb) record
    (gdb) cont
    Continuing.
    /build/gdb-KOFU8D/gdb-8.1/gdb/nat/x86-linux-dregs.c:146:
      internal-error: void x86_linux_update_debug_registers(lwp_info*):
        Assertion `lwp_is_stopped (lwp)' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

I had set one breakpoint before at ConsoleHtml::clear and hit that.
(To reproduce click menu Calculator - Clear.)
kalgebra seems to start around 30 treads.


I tried to find the first version showing that issue in debian and found
- gdb-minimal_7.10-1.1 works
- gdb-minimal_7.11.1-1 fails


A git bisect points to that commit:
398e081380a204e3b9fb4eb4da069ccf471f930e is the first bad commit
commit 398e081380a204e3b9fb4eb4da069ccf471f930e
Author: Pedro Alves <[hidden email]>
Date:   Wed Sep 30 19:23:39 2015 +0100

    x86/Linux: reenable all-stop on top of non-stop

    Since the record-btrace target now supports non-stop mode, we no
    longer need to force-disable as-ns on x86.

    gdb/ChangeLog:
    2015-09-30  Pedro Alves  <[hidden email]>

        * linux-nat.c (linux_nat_always_non_stop_p): Always return 1.
        * x86-linux-nat.c (x86_linux_always_non_stop_p): Delete.
        (x86_linux_create_target): Don't install
        x86_linux_always_non_stop_p.

:040000 040000 aa77d3a15c409479339b4e70e06a39b37de2e41b
42386dee55ce6dbfc8466dd1f54107d2e1af1949 M      gdb


That patch reverted on the current debian buster gdb-minimal_8.1-4+b1
package makes the assert go away (and seems working for my limited test).


Bugs 21051 and 22368 seem to be about the same issue.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

--- Comment #8 from Pedro Alves <palves at redhat dot com> ---
That patch enabled non-stop mode in the backend by default.  

Thus, doing  
  maint show target-non-stop off
works around it.

I can reproduce it locally with a simple threaded program on current upstream
master.

The problem is that the record never really supported multi-threaded programs
correctly.

When you do a "continue", record in turn issues a series of single-steps behind
the scenes, and records the side effects of each instruction.

With a threaded program, it single-steps the current thread, but lets the other
threads run free too, out of recording control...  So any memory change or side
effects caused by other threads are not recorded or replayed properly...  Or if
some other thread hits an event, the event is recorded without information of
which thread it was for...  Enabling non-stop by default in the target backend
runs into that assertion because the record code isn't prepared to handle
multiple threads.

The fix would probably be to serialize execution of threads (single-step each
thread in turn), and then make sure to replay the same order, at replay time.

The record-btrace target supports multi-threaded programs by serializing
threads too (record_btrace_target::wait), though that's simpler, since
record-btrace doesn't record any memory.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

astian at elude dot in changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |astian at elude dot in

--- Comment #9 from astian at elude dot in ---
*** Bug 22368 has been marked as a duplicate of this bug. ***

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

Radoslav Georgiev <rgeorgiev583 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rgeorgiev583 at gmail dot com

--- Comment #10 from Radoslav Georgiev <rgeorgiev583 at gmail dot com> ---
I managed to reproduce an assertion failure with the same message:

[Attaching after Thread 0x7fffecbf0ac0 (LWP 958) vfork to child process 1175]
[New inferior 4 (process 1175)]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Detaching vfork parent process 958 after child exec]
nat/x86-linux-dregs.c:146: internal-error: void
x86_linux_update_debug_registers(lwp_info*): Assertion `lwp_is_stopped (lwp)'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

These are the core dump files which GDB prompted me to create after the failure
of the aforementioned assertion:

https://my.pcloud.com/publink/show?code=XZOulN7ZCNxs8tozILz6YOI5RWutRQ5LAVaV
https://my.pcloud.com/publink/show?code=XZ0flN7ZVYt5ABk6tNSYUYFgNwD93VbAju4V
https://my.pcloud.com/publink/show?code=XZRflN7ZPiw8Dai5ud0Qbo7j6xcLkz67eVJy
https://my.pcloud.com/publink/show?code=XZ4flN7ZVBYedcBX01zjbFCI9vaWVXi052OX
https://my.pcloud.com/publink/show?code=XZhflN7ZTJVIttIzYmXMIE3PI6W9mh21P3DV

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug record/20456] gdb crash with record and d

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=20456

--- Comment #11 from Bernhard Übelacker <bernhardu at mailbox dot org> ---
(In reply to Radoslav Georgiev from comment #10)
> These are the core dump files ...

As a developer already wrote in comment #8 that he can reproduce the issue,
I guess for this issue no more core files are needed.
If I read this comment right then the issue is just the record feature
is not (yet) prepared to be run with multi-threaded processes.

However an improvement could print a warning if a user tries to use this
record feature on such a process, maybe also writing about the two given
workarounds in comment #8, and that a gdb crash has to be expected.

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