* 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).