Messages in this thread | | | Date | Tue, 6 Apr 1999 12:55:19 +0200 | From | Janos Farkas <> | Subject | StarOffice with 2.2.4/Re: Thread hang problem on 2.2.4 |
| |
On 1999-04-06 at 07:44:11, I wrote: > On 1999-04-05 at 17:02:01, Chris R. Jones wrote: > > I've been working on a linux program which uses threads very heavily, > > and I believe I've encountered a bug with either the linux kernel or > > glibc & linux-threads.
In the meantime, I managed to find out what happens with StarOffice. (Alex, could you please forward this to your hardly acquired StarOffice contact person? :)
It seems that since 2.2-pre8, the select() system call, among being more scalable to large fd sets, is more pedantic in checking its arguments. In particular, it doesn't allow the first argument being larger than about 5000; but for some reason, StarOffice likes to call select() with a first argument being trash, usually as high as a few millions.
The sanity check since 2.2-pre8 (and in all 2.2.x kernels) makes this return with -EINVAL, which seems to cause SO to retry the operation, not checking for progress on its file handles, thus sucking up CPU time, and essentially "freezing" network operations.
There isn't anything I could do by patching the kernel, it's clearly a bug in user space; although it might be caused by glibc, independent of StarOffice, tracking that should be a job for the guys at StarDivision.
Hint: it may be in glibc-linuxthreads [by looking at it, it seems to use poll() however, not select()], it could be even in glibc's poll() emulation [Chris, that's when it might be the same as your problem], or it could be simply in SO's code itself [possibly an uninitialized maxfd-like variable]; in which case, only Star Division can do anything about it.
[I'm open if they need to discuss this problem with me, and I also do speak... ehrm, write/read German if needed.]
Janos
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |