* one week to go until GDB 7.11 branch creation... @ 2016-01-18 3:44 Joel Brobecker 2016-01-20 16:32 ` Yao Qi 0 siblings, 1 reply; 6+ messages in thread From: Joel Brobecker @ 2016-01-18 3:44 UTC (permalink / raw) To: gdb-patches Hello, Just a quick reminder that the current plan, pending complications, is to create the GDB 7.11 branch next Monday. We currently have 2 items on the TODO, and patches have been posted for both. Nice! There is also a Maybe (C++ ABI tag does not work), but it's unclear to me whether this is branch-critical or not, and whether anyone is working on it. Jan? If there are other issues we are not aware of, please let us know! -- Joel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: one week to go until GDB 7.11 branch creation... 2016-01-18 3:44 one week to go until GDB 7.11 branch creation Joel Brobecker @ 2016-01-20 16:32 ` Yao Qi 2016-01-21 10:05 ` Joel Brobecker 0 siblings, 1 reply; 6+ messages in thread From: Yao Qi @ 2016-01-20 16:32 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches Joel Brobecker <brobecker@adacore.com> writes: Hi Joel, > If there are other issues we are not aware of, please let us know! Here are some issues, - some fails in test cases added by fort_dyn_array patch on some OS and targets. I reported them here https://sourceware.org/ml/gdb-patches/2016-01/msg00467.html and the original patch is https://sourceware.org/ml/gdb-patches/2015-10/msg00085.html - PR 19491, fail in gdb.base/multi-forks.exp - GDB sets breakpoint on the wrong place, if the file basename is identical to the current file basename. PR 19474. I posted a patch https://www.sourceware.org/ml/gdb-patches/2015-12/msg00321.html but it causes a regression. - As a result of the previous bug, GDB crashes in gdb.base/dprintf.exp. I posted a patch https://sourceware.org/ml/gdb-patches/2016-01/msg00323.html to avoid GDB crash. - A regression in trunk about arm stepping out of signal handler, patch is posted https://sourceware.org/ml/gdb-patches/2016-01/msg00377.html and I'll push it in after the regression testing. - A fail in gdb.threads/interrupted-hand-call.exp $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost interrupted-hand-call.exp' (gdb) PASS: gdb.threads/interrupted-hand-call.exp: dummy frame popped continue^M Continuing.^M FAIL: gdb.threads/interrupted-hand-call.exp: continue until exit (timeout) Remote debugging from host 127.0.0.1^M ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^M ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^ I suspect it is about a GDB PR about disappeared inferior, but I can't find the PR in bugzilla. I'll look into it. I'll update https://www.sourceware.org/gdb/wiki/GDB_7.11_Release later. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: one week to go until GDB 7.11 branch creation... 2016-01-20 16:32 ` Yao Qi @ 2016-01-21 10:05 ` Joel Brobecker 2016-01-21 15:10 ` Yao Qi 0 siblings, 1 reply; 6+ messages in thread From: Joel Brobecker @ 2016-01-21 10:05 UTC (permalink / raw) To: Yao Qi; +Cc: gdb-patches Hi Yao, On Wed, Jan 20, 2016 at 04:32:27PM +0000, Yao Qi wrote: > > If there are other issues we are not aware of, please let us know! > > Here are some issues, Thanks! > - some fails in test cases added by fort_dyn_array patch on some OS and > targets. I reported them here > https://sourceware.org/ml/gdb-patches/2016-01/msg00467.html > and the original patch is > https://sourceware.org/ml/gdb-patches/2015-10/msg00085.html For those, do they only affect Fortran, by any chance? If it is not a regression, then let's make this a non-blocking known issue. (communication between the author and myself has been infrequent, mostly my fault, but we may not get an answer in the near future). > - PR 19491, fail in gdb.base/multi-forks.exp Looks like an issue with the test itself, rather than a regression? > - GDB sets breakpoint on the wrong place, if the file basename is > identical to the current file basename. PR 19474. > I posted a patch > https://www.sourceware.org/ml/gdb-patches/2015-12/msg00321.html > but it causes a regression. This one is indeed annoying. What's the status? Looks like you are saying the patch you suggested introduces a regression too? Let's put it on the "blocking for branching" list for now. The idea would be: either we fix it before branching, or alternatively we branch, but only after knowing that the fix will likely be reasonable for backporting. > - As a result of the previous bug, GDB crashes in gdb.base/dprintf.exp. > I posted a patch > https://sourceware.org/ml/gdb-patches/2016-01/msg00323.html > to avoid GDB crash. OK. Let's indeed add this one to the list; crashes are never fun. > - A regression in trunk about arm stepping out of signal handler, patch > is posted https://sourceware.org/ml/gdb-patches/2016-01/msg00377.html > and I'll push it in after the regression testing. Good! > - A fail in gdb.threads/interrupted-hand-call.exp > > $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost interrupted-hand-call.exp' > > (gdb) PASS: gdb.threads/interrupted-hand-call.exp: dummy frame popped > continue^M > Continuing.^M > FAIL: gdb.threads/interrupted-hand-call.exp: continue until exit (timeout) > Remote debugging from host 127.0.0.1^M > ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^M > ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^ > > I suspect it is about a GDB PR about disappeared inferior, but I can't > find the PR in bugzilla. I'll look into it. A little confusing, at the very least, but if the program did terminate, I would say this issue is not blocking for the release. WDYT? > I'll update https://www.sourceware.org/gdb/wiki/GDB_7.11_Release later. Thanks a lot! -- Joel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: one week to go until GDB 7.11 branch creation... 2016-01-21 10:05 ` Joel Brobecker @ 2016-01-21 15:10 ` Yao Qi 2016-01-21 15:22 ` Pedro Alves 0 siblings, 1 reply; 6+ messages in thread From: Yao Qi @ 2016-01-21 15:10 UTC (permalink / raw) To: Joel Brobecker; +Cc: Yao Qi, gdb-patches Joel Brobecker <brobecker@adacore.com> writes: >> - some fails in test cases added by fort_dyn_array patch on some OS and >> targets. I reported them here >> https://sourceware.org/ml/gdb-patches/2016-01/msg00467.html >> and the original patch is >> https://sourceware.org/ml/gdb-patches/2015-10/msg00085.html > > For those, do they only affect Fortran, by any chance? If it is > not a regression, then let's make this a non-blocking known issue. > (communication between the author and myself has been infrequent, > mostly my fault, but we may not get an answer in the near future). As far as I can see, they only affect Fortran. If the author or someone else can't fix them before release, why do we still ship them in the release? Can't we revert the patch? Since they were added three months ago, it shouldn't be hard to remove them. > >> - PR 19491, fail in gdb.base/multi-forks.exp > > Looks like an issue with the test itself, rather than a regression? No ideas without further analysis. > >> - GDB sets breakpoint on the wrong place, if the file basename is >> identical to the current file basename. PR 19474. >> I posted a patch >> https://www.sourceware.org/ml/gdb-patches/2015-12/msg00321.html >> but it causes a regression. > > This one is indeed annoying. What's the status? Looks like you are > saying the patch you suggested introduces a regression too? Correct. > > Let's put it on the "blocking for branching" list for now. > The idea would be: either we fix it before branching, or alternatively > we branch, but only after knowing that the fix will likely be > reasonable for backporting. OK. >> - A fail in gdb.threads/interrupted-hand-call.exp >> >> $ make check >> RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost >> interrupted-hand-call.exp' >> >> (gdb) PASS: gdb.threads/interrupted-hand-call.exp: dummy frame popped >> continue^M >> Continuing.^M >> FAIL: gdb.threads/interrupted-hand-call.exp: continue until exit (timeout) >> Remote debugging from host 127.0.0.1^M >> ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^M >> ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^ >> >> I suspect it is about a GDB PR about disappeared inferior, but I can't >> find the PR in bugzilla. I'll look into it. > > A little confusing, at the very least, but if the program did terminate, > I would say this issue is not blocking for the release. WDYT? I am afraid not, the program didn't terminate, at least there is one thread, as far as I can tell. Again, nothing useful to say here without further analysis. PR 19508 is opened to track it. I set the target milestone of PR 19491, PR 19474, and 19508 to "GDB 7.11", so I don't write them down in the wikipage again. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: one week to go until GDB 7.11 branch creation... 2016-01-21 15:10 ` Yao Qi @ 2016-01-21 15:22 ` Pedro Alves 2016-01-21 15:24 ` Pedro Alves 0 siblings, 1 reply; 6+ messages in thread From: Pedro Alves @ 2016-01-21 15:22 UTC (permalink / raw) To: Yao Qi, Joel Brobecker; +Cc: gdb-patches On 01/21/2016 03:10 PM, Yao Qi wrote: >>> >> - A fail in gdb.threads/interrupted-hand-call.exp >>> >> >>> >> $ make check >>> >> RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost >>> >> interrupted-hand-call.exp' >>> >> >>> >> (gdb) PASS: gdb.threads/interrupted-hand-call.exp: dummy frame popped >>> >> continue^M >>> >> Continuing.^M >>> >> FAIL: gdb.threads/interrupted-hand-call.exp: continue until exit (timeout) >>> >> Remote debugging from host 127.0.0.1^M >>> >> ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^M >>> >> ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^ >>> >> >>> >> I suspect it is about a GDB PR about disappeared inferior, but I can't >>> >> find the PR in bugzilla. I'll look into it. >> > >> > A little confusing, at the very least, but if the program did terminate, >> > I would say this issue is not blocking for the release. WDYT? > I am afraid not, the program didn't terminate, at least there is one > thread, as far as I can tell. Again, nothing useful to say here without > further analysis. PR 19508 is opened to track it. Several tests have this racy issue with gdbserver. It'll usually manifest when running the main thread to exit while there are still other threads running. Notice how the test program doesn't gracefully terminate/join all threads before exiting. So gdb/gdbserver are processing something for one thread, and meanwhile the process exits. This is really the same as PR 18749. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: one week to go until GDB 7.11 branch creation... 2016-01-21 15:22 ` Pedro Alves @ 2016-01-21 15:24 ` Pedro Alves 0 siblings, 0 replies; 6+ messages in thread From: Pedro Alves @ 2016-01-21 15:24 UTC (permalink / raw) To: Yao Qi, Joel Brobecker; +Cc: gdb-patches On 01/21/2016 03:22 PM, Pedro Alves wrote: > On 01/21/2016 03:10 PM, Yao Qi wrote: >>>>>> - A fail in gdb.threads/interrupted-hand-call.exp >>>>>> >>>>>> $ make check >>>>>> RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost >>>>>> interrupted-hand-call.exp' >>>>>> >>>>>> (gdb) PASS: gdb.threads/interrupted-hand-call.exp: dummy frame popped >>>>>> continue^M >>>>>> Continuing.^M >>>>>> FAIL: gdb.threads/interrupted-hand-call.exp: continue until exit (timeout) >>>>>> Remote debugging from host 127.0.0.1^M >>>>>> ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^M >>>>>> ptrace(regsets_fetch_inferior_registers) PID=9710: No such process^ >>>>>> >>>>>> I suspect it is about a GDB PR about disappeared inferior, but I can't >>>>>> find the PR in bugzilla. I'll look into it. >>>> >>>> A little confusing, at the very least, but if the program did terminate, >>>> I would say this issue is not blocking for the release. WDYT? >> I am afraid not, the program didn't terminate, at least there is one >> thread, as far as I can tell. Again, nothing useful to say here without >> further analysis. PR 19508 is opened to track it. > > Several tests have this racy issue with gdbserver. It'll usually manifest when > running the main thread to exit while there are still other threads running. > Notice how the test program doesn't gracefully terminate/join all threads > before exiting. So gdb/gdbserver are processing something for one thread, > and meanwhile the process exits. This is really the same as PR 18749. BTW, I don't think this is a new issue, so I don't think it should be a blocker. In fact, we're much better handling these scenarios nowadays than in past releases. Not great, but better. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-01-21 15:24 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-18 3:44 one week to go until GDB 7.11 branch creation Joel Brobecker 2016-01-20 16:32 ` Yao Qi 2016-01-21 10:05 ` Joel Brobecker 2016-01-21 15:10 ` Yao Qi 2016-01-21 15:22 ` Pedro Alves 2016-01-21 15:24 ` Pedro Alves
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).