I have also been working in my spare time on packaging rssowl for FC5 [sic]. I can post my .spec file if wanted. Here's my list of unfixed libgcj bugs that need to be fixed before rssowl will run natively reliably. These are both threading bugs.
1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211 "Thread.interrupt sometimes causes abort if thread is already dead"
This gets hits about 25%-50% of the time on quitting rssowl, and occassionaly also when I press the little red stop button at the bottom of the window. I can provide a backtrace if wanted.
Unfortunately rssowl only saves any changes upon quit, so this means that any changes (including preferences and even the record of which feed items have been read) will be lost 25-50% of the time - unacceptable, obviously.
2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 "AttachCurrentThread() not working"
This is an old bug. It only triggered for me once I rebuilt gcc for Athlon (32bit) with a private threading patch, but now it triggers 100% of the time, every time I try to view the Dilbert comic in rssowl. Again, backtrace available on request. I am convinced that it is a real bug in the existing code, not a bug in my patch. After all, bad memory accesses don't always trigger SIGSEGVs. Sometimes they just cause memory corruptions. So probably, previously it was just causing memory corruptions instead of SIGSEGVs for some subtle reason.
Feel free to add to this list.
"Robin" == Robin Green greenrd@presidium.org writes:
Robin> 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211 Robin> "Thread.interrupt sometimes causes abort if thread is already dead"
I fixed this one in gcc cvs. The fix isn't on the 4.0 branch yet (the 4.0 branch is temporarily frozen) but I will move it over there after it reopens. (Feel free to remind me if I happen to forget.)
Robin> 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 Robin> "AttachCurrentThread() not working"
This one looks hard. The GC likes to intercept some pthread calls in order to do things like add the new stacks to the root set. Maybe there is some way we can make this work for Linux though.
Tom
On Sun, 2005-07-03 at 12:08 -0600, Tom Tromey wrote:
Robin> 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212 Robin> "AttachCurrentThread() not working"
This one looks hard. The GC likes to intercept some pthread calls in order to do things like add the new stacks to the root set. Maybe there is some way we can make this work for Linux though.
The attached trick appears to work. Rather than wrap the pthread_create symbol, we override it with our own implementation and then use a glibc runtime linker trick to get a pointer to the real pthread_create.
I can work up a submittable patch if you're in agreement with the general approach.
AG
"Anthony" == Anthony Green green@redhat.com writes:
Anthony> The attached trick appears to work. Rather than wrap the Anthony> pthread_create symbol, we override it with our own Anthony> implementation and then use a glibc runtime linker trick to Anthony> get a pointer to the real pthread_create.
This seems like a reasonable approach when libgcj is linked into the resulting executable. But how can it work if we dlopen() libgcj and then attach a previously-existing thread?
I was wondering if there was some /proc-reading approach (or something like that) that we could use to find information about threads.
Tom
On Wed, 2005-07-27 at 12:16 -0600, Tom Tromey wrote:
This seems like a reasonable approach when libgcj is linked into the resulting executable. But how can it work if we dlopen() libgcj and then attach a previously-existing thread?
It can't; this only solves the problem reported. We could force tricky programmers to do thread registrations themselves. The PyLucene people probably solved this in some way.
I was wondering if there was some /proc-reading approach (or something like that) that we could use to find information about threads.
Well, I'm guessing that the "[stack]" line /proc/<pid>/task/<pid>/maps describes the extent of each stack. Is this an interface we can depend on over all Linux implementations? (isn't /proc optional during kernel configuration?)
AG
java-devel@lists.fedoraproject.org