On Sat, Jul 3, 2010 at 3:48 PM, OvermindDL1 <overmind...@gmail.com> wrote:
> On Sat, Jul 3, 2010 at 5:47 AM, Alex Sadovsky <alexey...@gmail.com> wrote:
>> On Sat, Jul 3, 2010 at 10:46 AM, OvermindDL1 <overmind...@gmail.com> wrote:
>>>
>>> On Fri, Jul 2, 2010 at 11:03 PM, OvermindDL1 <overmind...@gmail.com>
>>> wrote:
>>> > I am still trying to figure out if it is something with my setup or
>>> > what, but everytime my server gets under any tiny bit of load from
>>> > multiple users, it just 'stops', will not respond to localhost, just
>>> > 'nothing', in both debug and release.
>>> >
>>> > If I run it under debug in Visual Studio, VS (or one of my plugins,
>>> > unsure anymore, it all just melds together over time) reports that the
>>> > app is deadlocked. This happens with even simple examples that
>>> > require a session, like the Bob Smith example (which is what I am
>>> > trying to trace it through currently since it is so simple).
>>> >
>>> > Windows XP SP3.
>>> > 4 gigs of ram (although XP 32-bit only uses ~3gigs).
>>> > Computer is not under load.
>>> > Using the simple Bob Smith example that comes with the latest Wt
>>> > Master/head, all build types, just get two people to connect at once,
>>> > seems to cause a deadlock (very easy to reproduce when they refresh
>>> > the page repeatedly). Any thoughts?
>>>
>>>
>>> Interestingly, the browser still initiates a connection to the server,
>>> but never gets a response, it just hangs waiting for the response...
>>>
>>
>> I can confirm the same behavior on a Win2003r2/32bit sytem. I haven't dug
>> into this too much though.
>
> I am using Visual Studio 2005 Standard for note, and although I have a
> deadlock detector, I do not have one that can identify them ahead of
> time nor what causes them. I might try to look at this later if I get
> a chance.
Actually I have a moment, and did just a quick check to see what the threads do.
Using the bobsmith.wt.exe demo, I launched the debug version (so I can
see it stack data easily), opened up a browser, and held down refresh
for a couple of seconds. At that time I saw all the worker threads
just die, vanish, kaput, there were two threads left at that point,
one was some wmifree thread, but it disappeared a few seconds later,
and the last one remaining is the mainCRTStartup thread, the top of
its stack holding:
bobsmith.wt.exe!boost::this_thread::interruptible_wait+0x211
So it is still waiting for the threads to return, but since they all
died, it does not.
Running it again, I caught the entire stack for the second thread that
lives for a few seconds after the thing dies, it is:
ADVAPI32.dll!WmiFreeBuffer+0x24e
kernel32.dll!GetModuleFileNameA+0x1ba
I ran it again, and set the thread count to 1, and debugged that
thread, apparently when it seems to 'lock up', the ASIO do_one
function never returns, it never gets signal from the socket that
there is incoming data, and then the socket closes, which kills ASIO.
Debugging into the actual GetQueuedCompletionStatus call in ASIO, it
seems that it always return status code WAIT_TIMEOUT when not serving
anything, but the last time through, the one that it is killed right
after, the error code is 0.
Debugging into it and tracing it line by line, it seems that the
thread stopped flag becomes set, trying to find out why...
Searched for every place that variable is ever set to 1, which is
apparently only one place, the stop() method, to try to figure out
what is setting it, and it is hit, so something is indeed setting it,
tracing back up reveals it is called by:
bobsmith.wt.exe!boost::asio::detail::win_iocp_io_service::work_finished()
Line 315 C++
bobsmith.wt.exe!boost::asio::detail::win_iocp_io_service::auto_work::~auto_work()
Line 641 C++
bobsmith.wt.exe!boost::asio::detail::win_iocp_io_service::do_one(bool
block=true, boost::system::error_code & ec={...}) Line 548 + 0x19
bytes C++
bobsmith.wt.exe!boost::asio::detail::win_iocp_io_service::run(boost::system::error_code
& ec={...}) Line 229 + 0xe bytes C++
bobsmith.wt.exe!boost::asio::io_service::run() Line 68 + 0xf bytes C++
bobsmith.wt.exe!http::server::Server::run() Line 213 C++
So basically, it is saying that it is running out of work, hmm...
After some more digging, it seems that the on_completion handler for
handling a new socket is failing for some reason, which is causing the
work to be decremented, without it ever being incremented, trying to
figure out what is going on here, but regardless, with the auto-work
holder is released right after it, it causes the thread to close since
there is no more work.
Okay, figured out what is closing it all, the IO completion port call
returns ERROR_SEM_TIMEOUT, so the semaphore is timing out, and it
seems like it is timing out *before* the timeout call, this generally
indicates a failure condition in the port, hmm...
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
