rssowl: libgcj bugs that need fixing for it to run

[Robin Green]

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

[Tom Tromey]

> >>>> "Robin" == Robin Green
> <greenrd(a)presidium.org&gt; 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

[Anthony Green]

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

[Tom Tromey]

> >>>> "Anthony" == Anthony Green
> <green(a)redhat.com&gt; 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

[Anthony Green]

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