From: Robert M. <bob...@bo...> - 2005-05-27 01:05:38
|
Hi all I wrote a server application for the company I work for using SBCL and SBCL's threads. Unfortunately it's been crippled by a bug causing segmentation faults and other errors. It appears to be the same bug found when running the allocation / interrupt test in tests/threads.impure.lisp of the SBCL source tree. As of Tuesday, if a fix for this bug isn't found, the project will be binned, my name will be mud for choosing SBCL and all use of common lisp will be banned from further projects thus making my job miserable. I've been urgently trying to fix this bug on my own and have gotten some outside help from Marco but neither of us seem to be getting anywhere. Please, I'd appreciate it if everyone who has any suspicion at all of what causes this bug please investigate it and help fix it. I can't offer anything in return except sincere gratitude. SBCL is a great piece of software and I'd hate to be kept away from it simply because my employer has totally lost confidence in it due to this one solitary but persistent bug. -- Robert Marlow <bob...@bo...> |
From: <da...@te...> - 2005-05-27 11:33:39
|
On Fri, May 27, 2005 at 09:05:28AM +0800, Robert Marlow wrote: > SBCL's threads. Unfortunately it's been crippled by a bug causing > segmentation faults and other errors. It appears to be the same bug > found when running the allocation / interrupt test in > tests/threads.impure.lisp of the SBCL source tree. The interrupt-thread bug has a low priority for fixing (at least for me) because it only shows up in intense use of interrupt-thread, and, well, your code would have to be pretty strange to do that a lot. interrupt-thread is for debugging and introspection, not for use as a general programming construct When you say that your bug "appears to be the same bug", do you mean that you're abusing interrupt-thread in the same way, or that you see similar symptoms with /different/ usage patterns? If you are not using interrupt-thread in anger and can isolate a better test case that you know is actually due to /your/ bug and not just something with similar symptoms, that would probably be much more help to developers than these threats of "we may never use lisp again and it will be all _your_ fault". If you are using interrupt-thread seriously, I would probably advise that you consider some other arrangement (for example, a producer/ consumer setup is common in a lot of apps and can be done with the condition variables). Without knowing the specifics of your app it's hard to advise in more detail -dan |
From: Robert M. <bob...@bo...> - 2005-05-27 19:37:32
|
On Fri, 2005-05-27 at 12:33 +0100, da...@te... wrote: > The interrupt-thread bug has a low priority for fixing (at least for > me) because it only shows up in intense use of interrupt-thread, and, > well, your code would have to be pretty strange to do that a lot. > interrupt-thread is for debugging and introspection, not for use as > a general programming construct Are you sure the bug has anything to do with interrupts though? I thought noone understood what caused this bug and consequently it's quite possible that it can be triggered by things other than interrupts. If you know differently, please tell me so I can stop wasting time on it. I always thought the bug had more to do with making allocations atomic and using interrupts was just a conveniant way to test it. > When you say that your bug "appears to be the same bug", do you mean that > you're abusing interrupt-thread in the same way, or that you see similar > symptoms with /different/ usage patterns? Very similar symptoms but different usage patterns. We don't use interrupts. I have two different systems which suffer the same problem. The only thing I can think of that they share besides threads is use of sb-bsd-sockets (indirectly through kmrcl's socket interface) for serving tcp connections. > If you are not using interrupt-thread in anger and can isolate a better > test case that you know is actually due to /your/ bug and not just something > with similar symptoms, that would probably be much more help to > developers than these threats of "we may never use lisp again and it will > be all _your_ fault". Isolating the bug is one of the problems I'm having. That's why I keep asking about known problems so I can use them as hints on where to look. So far that interrupt test is the best lead I've got. I'm not making any such foolish threats, nor am I looking for anyone to blame. I'm just asking for help, Dan. Really, I wonder what drives you to read such nonsense into what I write. -- Robert Marlow <bob...@bo...> |