Re: Incorrect behavior in case of watchpoint
Aetf <[email protected]>
| Newsgroups | gmane.comp.kde.users.kdevelop |
|---|---|
| Message-ID | <CANHr+NFU0wv+k_fembqc857qGy3YM840S3Q8QY5U58-C0w7Uug@mail.gmail.com> |
PS: Reported on bug tracker: https://bugs.kde.org/show_bug.cgi?id=384368 On Mon, Sep 4, 2017 at 5:55 PM Aetf <[email protected]> wrote: > Hi, > > I can see a few issues here. > > 1. BreakpointModel gets updated when user creating watch points directly > using command. The location reported by GDB includes the "-location " part, > but since we are quoting the entire string, GDB interprets the entire > string as an option, rather than only the "-location" part. > 2. Even though we recognize the location and only quote remaining > expression, GDB/MI which is the protocol we use to communicate with GDB > actually doesn't support "-l/-location" option. see [1] > 3. When starts new session, KDevelop tries to automatically reapply all > break/watch points saved in BreakpointModel. But the command fails due to > above reason. However there shouldn't be an endless loop. Once the > command fails, it should set the error message in the Breakpoint toolview > and continue. But maybe I'm just missing something. > > The fix would be > 1. In mibreakpointcontroller.cpp:358, detect and quote only the expression > part, this is easy. > 2. Find a way to emulate the "-location" option. Possible solutions: > 2.1 Take the address of the expression when watch point got set and > save that in BreakpointModel. But addresses are likely to change between > runs > 2.2 Simply remove "-location" part and set it as a normal watch point. > But likely at the very begining of the program, the expression is out of > scope. > 2.3 Skip it. IMHO even normal watchpoints should be skipped. As they > rely on expressions that are hardly valid at this time. > 3. Desired behavior should be display the error in Breakpoint toolview, > rather than entering an endless loop. However I didn't find which part of > the code is causing the loop after a quick of the codebase. And the desired > behavior is already implemented. This will need more investigate. > > [1] > https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html#GDB_002fMI-Breakpoint-Commands > > Cheers, > Aetf > > On Mon, Sep 4, 2017 at 7:48 AM Aleix Pol <[email protected]> wrote: > >> On Fri, Sep 1, 2017 at 6:32 PM, Aetf <[email protected]> wrote: >> > Hi, >> > >> > I'm afraid I don't have much time for this at the moment. Actually this >> has >> > been on my todo list for a while... I'll take a look at it soon. >> > >> > Cheers, >> > Aetf >> > >> > On Fri, Sep 1, 2017 at 7:55 AM Aleix Pol <[email protected]> wrote: >> >> >> >> On Mon, Aug 21, 2017 at 1:54 PM, Aleksey Midenkov <[email protected]> >> >> wrote: >> >> > I've set watchpoint with command `watch -l` and it was saved in >> >> > KDevelop session. Now it doesn't start debug session because it ends >> >> > up in endless loop: >> >> > >> >> > (gdb) 2106-break-watch "-location m_part_spec.start_part" >> >> > 2106^error,msg="-break-watch: Unknown option ``location >> >> > m_part_spec.start_part''" >> >> > (gdb) 2107-break-watch "-location m_part_spec.start_part" >> >> > 2107^error,msg="-break-watch: Unknown option ``location >> >> > m_part_spec.start_part''" >> >> > (gdb) 2108-break-watch "-location m_part_spec.start_part" >> >> > 2108^error,msg="-break-watch: Unknown option ``location >> >> > m_part_spec.start_part''" >> >> > (gdb) 2109-break-watch "-location m_part_spec.start_part" >> >> > 2109^error,msg="-break-watch: Unknown option ``location >> >> > m_part_spec.start_part''" >> >> > (gdb) 2110-break-watch "-location m_part_spec.start_part" >> >> > 2110^error,msg="-break-watch: Unknown option ``location >> >> > m_part_spec.start_part''" >> >> > ... >> >> > >> >> > Though I've managed to delete breakpoint from Breakpoints tab and >> start >> >> > again. >> >> >> >> Hey Aetf, >> >> Any idea why that could be? >> >> >> >> Aleix >> >> >> >> PS: Aleksey, can you make sure this is reported in bugs.kde.org? >> >> Hi Aetf, >> Maybe you can give us some pointers in case someone else can/wants to fix >> it? >> >> Aleix >> >