Suddenly seeing multiple Seti zombie threads?

At some point in the last few days, I've started seeing multiple SETI zombie threads. This used to work fine and I'm running the same version of BOINC that I've been running for a long time. I also notice that SETI seems to have reverted to running the 32-bit client, where I was running the x86_64 for a long time.

I'm running BOINC client version 5.10.45 for x86_64-pc-linux-gnu, AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ [Family 15 Model 67 Stepping 3], Linux: 2.6.25.10-86.fc9.x86_64.

PID PPID C STIME TTY TIME CMD

7224 7033 0 09:13 ? 00:00:00 setiathome-5.27.i686-pc-linux-gnu
7225 7224 0 09:13 ? 00:00:00 setiathome-5.27.i686-pc-linux-gnu
7226 7225 99 09:13 ? 01:43:33 setiathome-5.27.i686-pc-linux-gnu
7227 7225 0 09:13 ? 00:00:00 setiathome-5.27.i686-pc-linux-gnu

7508 7033 0 10:46 ? 00:00:00 setiathome-5.27.i686-pc-linux-gnu
7509 7508 0 10:46 ? 00:00:00 setiathome-5.27.i686-pc-linux-gnu
7510 7509 99 10:46 ? 00:10:06 setiathome-5.27.i686-pc-linux-gnu
7511 7509 0 10:46 ? 00:00:00 setiathome-5.27.i686-pc-linux-gnu

I don't know if this will help, but I just encountered the same problem running SETI on FreeBSD 7.0-RELEASE with BOINC 6.2.14 (bleeding edge). The WUs would run normally until fraction done was equal to 1.000000 and then they would swap out and hang. Once both running WUs finished (dual CPU), BOINC would not start any further WUs unless I GUIed it and suspended the two hangs that just occurred. Even then they wouldn't finish up and transmit, and I eventually got a queue full of duds. A ps -A command would show 8 threads for two WUs while the processes were running, two of which were getting large amounts of CPU. All thread names ended with the characters LINUX-GNU.
I fixed the problem by doing a make deinstall on the BOINC client port, then a MAKE CONFIG to uncheck the "download LINUX work units" option, and a MAKE INSTALL again. Now I have just two fine and dandy threads with names ending in portbld-freebsd that seem to be doing their job. When I restarted the system, the duds quickly finished up and transmitted back to STARFLEET COMMAND and I got more queued-up work. If it doesn't hang again overnight, I'm going to go buy a quad core CPU and go to WARP 2.