Re: gdb 6.2 blockers

Re: gdb 6.2 blockers

[Michael Elizabeth Chastain]

ac> BTW, I did try to reproduce this bug.  Mainline GDB and manythreads.exp 
ac> appear to work everytime on NPTL based FC2 and RHEL2 GNU/Linux systems 
ac> (well at least for the 30+ test runs I tried).  That wasn't the case 
ac> with 6.1.

Cool.  Could you cc: gdb-gnats on that?  I'm trying to use gnats to
collect history for complicated bugs like this.

I'm adding an RHEL3 machine soon.  hp test drive has an eight processor
machine running RHEL3!

ac> We should probably mention this fix in the NEWS file, and the apparent 
ac> linuxthreads regression in PROBLEMS.

If the PR is listed in PROBLEMS then it's totally okay with me.

(In my dream world, a user sees the PR number in PROBLEMS, reads the PR
to acquire all the information that we've discovered, and becomes
motivated to fix the problem and join the gdb developer community).

Michael C

Re: gdb 6.2 blockers

[Daniel Jacobowitz]

On Wed, Jul 07, 2004 at 11:26:32AM -0400, Andrew Cagney wrote:
> More edits:
> 
> >1650: I suspect this is really a kernel race condition.
> >I remember that Jeff was pointing out that the bug this tickles is a race 
> >condition (hence isn't always reproducable).  The fix for NPTL involves 
> >kernel changes, I'm not sure about linuxthreads.
> I couldn't get the test to fail on NPTL -> linuxthreads specific.

Ditto; one failure mode on LinuxThreads is:
(gdb) PASS: gdb.threads/manythreads.exp: info threads
continue
Continuing.
PASS: gdb.threads/manythreads.exp: second continue
(gdb) Quit
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 2

We stop threads for no apparent reason and then the C-c is handled at
the prompt.

Another is:
(gdb) PASS: gdb.threads/manythreads.exp: shell stty intr '^C'
continue
Continuing.
PASS: gdb.threads/manythreads.exp: first continue
/opt/src/gdb/src/gdb/lin-lwp.c:645: internal-error: wait_lwp: Assertion `lp->status == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
FAIL: gdb.threads/manythreads.exp: stop threads 1 (GDB internal error)

Jeff's presumably right about the race condition.  Did he investigate
at all?  The error means the waitstatus state machine in lin-lwp is
somehow broken.

-- 
Daniel Jacobowitz

Re: gdb 6.2 blockers

[Andrew Cagney]

More edits:

> 1650: I suspect this is really a kernel race condition.
> I remember that Jeff was pointing out that the bug this tickles is a race condition (hence isn't always reproducable).  The fix for NPTL involves kernel changes, I'm not sure about linuxthreads.
I couldn't get the test to fail on NPTL -> linuxthreads specific.

1704/1677: which is `under control' but a true must fix.

MAINTAINERS: I guess my admin task is to get its membership to reflect 
current (C) assignment reality.

Java: The stuff that Jeff's posting.

(and one other thing, I'll start a separate thread)

> HP/UX: ``regressions''
> This needs to be balanced against all the additional tests that do now pass.  Some bits are working much better than ever before, just not all :-)
> 
> vsyscall:
> For those following BFD you'll see I'm having fun closing this :-)
> 
> PIE:
> This stuff needs to be reviewed/merged.
> 
> inter-cu:
> This stuff needs to be reviewed/merged.
> 
> e500:
> Architecture problems.  Also dw_op_piece, xregset, ...

xregset

dw_op_piece

Andrew

Re: gdb 6.2 blockers

[Michael Elizabeth Chastain]

> anyone got a chance to look at PR# 1704 ??

Lemme take a quick look ...

The stack trace looks just like #1677.

Bob Rossi submitted a patch to fix this, Eli Z approved the patch,
I challenged Eli's approval (because I think it's a symtab patch,
but Eli thinks it's generic), the symtab maintainers Jim and Elena
haven't said anything.

Jim or Elena, can you look at this patch?  Both Eli and I believe
that it's okay.

  http://sources.redhat.com/ml/gdb-patches/2004-06/msg00654.html
  Re: -file-list-exec-sourc-files

Michael C

Re: gdb 6.2 blockers

[Manoj Iyer]

anyone got a chance to look at PR# 1704 ??

Thanks
Manjo

On Tue, 6 Jul 2004, Michael Elizabeth Chastain wrote:

> ac> - 1650 is an issue, but even there I'm wondering how much.  It's ticking
> ac> a horrible nasty race condition and may not be a real problem in the
> ac> field - do people really run 100 thread programs using linuxthreads.
>
> 1650, manythreads.exp, works every time with gdb 6.1.1.
> So if there's a kernel race condition then gdb does not trigger it
> and gdb HEAD does.  This is a user-visible regression.
>
> ac> - architecture specific problems HP/UX, and much of e500, that can be
> ac> committed after the branch
>
> 1692 is not arch-specific.  The bug was introduced by a change in
> bp_stop_status, and partially fixed by a change in bp_stop_status.
> gdb recognizes its watchpoints now, but cannot backtrace after
> hitting one.
>
> The 32-vs-64-bit register change is definitely arch-specific.
>
> All the changes are available at:
>
>   http://www.shout.net/~mec/sunday/2004-07-02-hpux/difference/6.1-HEAD-0.html
>
> I don't accept your conclusion that changes which manifest on hpux
> must be in arch-specific code.  I won't know until I dig into each
> of the 14 test scripts with regressed results.  It's up to me to do
> that and file PR's.
>
> Michael C
>

Re: gdb 6.2 blockers

[Andrew Cagney]

> ac> - 1650 is an issue, but even there I'm wondering how much.  It's ticking 
> ac> a horrible nasty race condition and may not be a real problem in the 
> ac> field - do people really run 100 thread programs using linuxthreads.
> 
> 1650, manythreads.exp, works every time with gdb 6.1.1.
> So if there's a kernel race condition then gdb does not trigger it
> and gdb HEAD does.  This is a user-visible regression.

BTW, I did try to reproduce this bug.  Mainline GDB and manythreads.exp 
appear to work everytime on NPTL based FC2 and RHEL2 GNU/Linux systems 
(well at least for the 30+ test runs I tried).  That wasn't the case 
with 6.1.

We should probably mention this fix in the NEWS file, and the apparent 
linuxthreads regression in PROBLEMS.

Andrew

Re: gdb 6.2 blockers

[Michael Elizabeth Chastain]

ac> - 1650 is an issue, but even there I'm wondering how much.  It's ticking 
ac> a horrible nasty race condition and may not be a real problem in the 
ac> field - do people really run 100 thread programs using linuxthreads.

1650, manythreads.exp, works every time with gdb 6.1.1.
So if there's a kernel race condition then gdb does not trigger it
and gdb HEAD does.  This is a user-visible regression.

ac> - architecture specific problems HP/UX, and much of e500, that can be 
ac> committed after the branch

1692 is not arch-specific.  The bug was introduced by a change in
bp_stop_status, and partially fixed by a change in bp_stop_status.
gdb recognizes its watchpoints now, but cannot backtrace after
hitting one.

The 32-vs-64-bit register change is definitely arch-specific.

All the changes are available at:

  http://www.shout.net/~mec/sunday/2004-07-02-hpux/difference/6.1-HEAD-0.html

I don't accept your conclusion that changes which manifest on hpux
must be in arch-specific code.  I won't know until I dig into each
of the 14 test scripts with regressed results.  It's up to me to do
that and file PR's.

Michael C

gdb 6.2 blockers

[Andrew Cagney]

Hello,

The first thing to do is look over what's already been fixed, and why we 
should push out a new release:

- signal trampolines ``work'' (ignoring kernel bugs :-)
- dwarf 2 cygwin support
- lots of new (or revised) native configurations
- this kvm thingie whats it (mark needs a news entry)
- the `start' command
- ppc64 is ``so much better''
- what else?

however, onto the issue.  Here's a list of what I know of that could 
potentially block 6.2:

1650: I suspect this is really a kernel race condition.
I remember that Jeff was pointing out that the bug this tickles is a 
race condition (hence isn't always reproducable).  The fix for NPTL 
involves kernel changes, I'm not sure about linuxthreads.

HP/UX: ``regressions''
This needs to be balanced against all the additional tests that do now 
pass.  Some bits are working much better than ever before, just not all :-)

vsyscall:
For those following BFD you'll see I'm having fun closing this :-)

PIE:
This stuff needs to be reviewed/merged.

inter-cu:
This stuff needs to be reviewed/merged.

e500:
Architecture problems.  Also dw_op_piece, xregset, ...

I think we can split this into three problems:

- 1650 is an issue, but even there I'm wondering how much.  It's ticking 
a horrible nasty race condition and may not be a real problem in the 
field - do people really run 100 thread programs using linuxthreads.

- architecture specific problems HP/UX, and much of e500, that can be 
committed after the branch

- new features - inter-cu, PIE, VSYSCALL, inter-cu, xregset? dw_op_piece
These should all go into the mainline.  In some cases, these have been 
missing for years.

Andrew