[fedora-java] Eclipse + CVS issues

[Andrew Overholt]

Hi,

We have two issues with CVS that I'd like to sort out and hopefully get
fixes into our gcc RPMs before their FC4 update.

1. checkouts of large-ish projects (GNU Classpath is something I've used as
   a test case) get "stuck" at about 83% finished.  This is about the best
   information I have at this point, but tests with combinations of stock
   FC4 gcc (4.0.0-8, I believe) and stock FC4 Eclipse (3.1.0.M6.22 or
   something like that) or rawhide gcc (4.0.1-x) and rawhide Eclipse
   (3.1.0_fc-2) would be greatly appreciated.  If we can narrow down when
   this problem occurred, it would help in finding its cause.  I don't
   remember this happening with what we had around FC4 release time.  Also,
   does CVS compression level affect this?

2. switching to the team synchronization perspective throws an error [1].
   There's a similar bug [2], but I'm not sure if they're the same thing.
   I'm not sure if these are related to problem 1. above.

If we can get some back traces and maybe some gdbing going on, hopefully we
can track these bugs down.

This is how I usually debug this kind of thing:  install eclipse-debuginfo
and gcc-debuginfo.  Once I've got Eclipse in the state that I want it, I
attach to that process with gdb (ps aux | grep java .. get the process #
... gdb /usr/bin/java <process id from above>).  There are usually around
15 threads and I think the CVS one is usually # 5.  You can see thread
information with the gdb command 'info threads'.  Switching between threads
is easy ('thread x') and you can get back traces for any of them with 'bt'
(note that I'm just putting the quotes around the gdb commands but they're
not necessary).  You can steph through things with 's' and continue with
'c'.  I read this page [3] once and it helped with signal ignoring.  I'm
not sure if it's necessary, but I've got this in my .gdbinit to deal with
it:

  handle SIGPWR nostop noprint
  handle SIGXCPU nostop noprint

It'll be great when we get full JDWP support in GNU Classpath and gcc so
that debugging these library issues (I've already determined that this
isn't a native compilation issue) will be easier.

Thanks,

Andrew

[1]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163079

[2]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161518

[3]
http://gcc.gnu.org/java/gdb.html