You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OS and version of remote machine (if applicable): SUSE Linux Enterprise Server 15-SP4
GDB / LLDB version: GDB 14.1
Bug Summary and Steps to Reproduce
Bug Summary: The debugger hangs when a breakpoint is hit in the presence of a GDB frame-filter. This happens even if the frame filter is returning an untouched frame iterator. No such issues occur when running GDB directly from CLI.
Steps to reproduce:
Place a breakpoint that will be hit during program execution.
Run a program.
Attach to it using the provided debugger configuration (I assume this bug is also applicable for launch requests)
Have the program hit a breakpoint
Observe that the debugger hangs when a breakpoint is hit.
I'm submitting this issue since I think it would be really nice to be able to use the cppdbg debugger while having a frame filter applied.
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8566) ->(gdb)\n"},"seq":1302}
1: (8566) ->(gdb)
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8567) 1035: elapsed time 26\n"},"seq":1304}
1: (8567) 1035: elapsed time 26
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8573) Send Event AD7BreakpointEvent\n"},"seq":1306}
1: (8573) Send Event AD7BreakpointEvent
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"Execute debugger commands using \"-exec <command>\", for example \"-exec info registers\" will list registers in use (when GDB is the debugger)\n"},"seq":1308}
Execute debugger commands using "-exec <command>", forexample "-exec info registers" will list registersin use (when GDB is the debugger)
--> E (stopped): {"type":"event","event":"stopped","body":{"reason":"breakpoint","threadId":135549,"allThreadsStopped":true,"source":{"name":"extended-capabilities.dml","path":"/disk2/tsonono/repos/simics-base/src/devices/dml-lib/pcie/extended-capabilities.dml","sources":[],"checksums":[]},"line":246,"column":1},"seq":1310}
<-- C (threads-15): {"command":"threads","type":"request","seq":15}
--> R (threads-15): {"type":"response","request_seq":15,"success":true,"command":"threads","body":{"threads":[{"id":135549,"name":"mini-python [135549]"},{"id":135566,"name":"mini-python [135566]"},{"id":135568,"name":"mini-python [135568]"},{"id":135570,"name":"mini-python [135570]"},{"id":135571,"name":"mini-python [135571]"},{"id":135580,"name":"mini-python [135580]"},{"id":136031,"name":"simics-poll [136031]"}]},"seq":1313}
<-- C (stackTrace-16): {"command":"stackTrace","arguments":{"threadId":135549,"startFrame":0,"levels":20},"type":"request","seq":16}
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8749) <-1036-list-features\n"},"seq":1316}
1: (8749) <-1036-list-features
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8749) ->1036^done,features=[\"frozen-varobjs\",\"pending-breakpoints\",\"thread-info\",\"data-read-memory-bytes\",\"breakpoint-notifications\",\"ada-task-info\",\"language-option\",\"info-gdb-mi-command\",\"undefined-command-error-code\",\"exec-run-start-option\",\"data-disassemble-a-option\",\"simple-values-ref-types\",\"python\"]\n"},"seq":1318}
1: (8749) ->1036^done,features=["frozen-varobjs","pending-breakpoints","thread-info","data-read-memory-bytes","breakpoint-notifications","ada-task-info","language-option","info-gdb-mi-command","undefined-command-error-code","exec-run-start-option","data-disassemble-a-option","simple-values-ref-types","python"]
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8749) ->(gdb)\n"},"seq":1320}
1: (8749) ->(gdb)
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8751) 1036: elapsed time 2\n"},"seq":1322}
1: (8751) 1036: elapsed time 2
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8753) <-1037-stack-list-arguments --thread 1 2 0 84\n"},"seq":1324}
1: (8753) <-1037-stack-list-arguments --thread 1 2 0 84
Additional information
It's always the -stack-list-arguments that is the last command in the trace.
My frame_filter.py file:
importgdbclassFrameFilter():
def__init__(self):
# Frame filter attribute creation.## 'name' is the name of the filter that GDB will display.## 'priority' is the priority of the filter relative to other# filters.## 'enabled' is a boolean that indicates whether this filter is# enabled and should be executed.self.name="Foo"self.priority=100self.enabled=True# Register this frame filter with the global frame_filters# dictionary.gdb.frame_filters[self.name] =selfdeffilter(self, frame_iter):
returnframe_iterFrameFilter()
The text was updated successfully, but these errors were encountered:
Thank you for reporting this issue. We’ll let you know if we need more information to investigate it. Additionally, if you're working with GDB/LLDB, please note that the code is open source at https://github.com/microsoft/MIEngine/wiki/Contributing-Code . Your contributions are always welcome and appreciated.
Environment
Bug Summary and Steps to Reproduce
Bug Summary: The debugger hangs when a breakpoint is hit in the presence of a GDB frame-filter. This happens even if the frame filter is returning an untouched frame iterator. No such issues occur when running GDB directly from CLI.
Steps to reproduce:
I'm submitting this issue since I think it would be really nice to be able to use the
cppdbg
debugger while having a frame filter applied.Debugger Configurations
Debugger Logs
Additional information
It's always the
-stack-list-arguments
that is the last command in the trace.My frame_filter.py file:
The text was updated successfully, but these errors were encountered: