I see the same thing and thought it was my code.
> From: "Hancock, David (DHANCOCK)" <DHANCOCK@...>
> Subject: Wedged threads
> Date: Mon, 10 Mar 2003 14:37:29 -0500
> The symptoms are that NO webkit threads seem to respond to browser requests.
> Sometimes there's a core dump, which gets labeled with the pid, I'm assuming
> (such as core.34172, where 34171, 34170, etc. are Webkit processes. Loading
> the core in the debugger tells me that ThreadedAppServer encountered a
> segmentation fault (signal 11). There's nothing labeled in the stack trace,
> just memory addresses, so I can't tell what function was executing. netstat
> reports that there's a server listening (we're using 8086 for WebKit), and
> in fact, we can do 'telnet localhost 8086' and get connected. (Of course,
> we can't do more at that point because it's looking for request data
> marshalled into some structure we don't know how to recreate from the
> command line!) But at least there's a listening socket.
> When this occurs, stopping and starting the ThreadedAppServer clears the
> problem, but the processes need to be 'kill -9'ed before they'll die.
Dear webware community. We just found what I think is some odd behavior
with version 0.8. We installed it on a windows box using Apache as the
webserver. This was a clean install on a new development machine, all our
other machines were upgrades from version 0.7. And as per our usual
install procedure we changed the webkit default context to the apache
document root (ie htdocs) so that servlets can be run from there. Now when
we tried to run a test servlet we got an error that said the default
context was wrong. After much hunting to try and figure out why the
default context was not loading we discovered that the __init__.py file was
automatically created in the root context. We did not notice this on any
of our other machines because they were upgrades and if I remember
correctly version 7 did create them automatically. Any thoughts as to why