On 06/11/2015 12:54 PM, William A Rowe Jr wrote:
On Thu, Jun 11, 2015 at 11:09 AM, Andy Wang <aw...@ptc.com
<mailto:aw...@ptc.com>> wrote:
On 06/11/2015 09:02 AM, William A Rowe Jr wrote:
Sounds telling. Can you get your installer to stall without
invoking
httpd.exe - and then attempt to start httpd outside of the
installer on
the same machine? Something going on within the installer may be
interacting with the winsock stack. If so, with the installer
frozen
the problem should occur outside of the installer process, I'd
expect.
The installer never actually stalls either. it continues to process
a few things and then eventually it needs to make a request to httpd
to make sure it's up. At that point, the installer hangs waiting
for response. the interesting thing is the TCP handshake and GET
request are both actually completed, so there's no other timeout.
So the process primary thread is "hung" because of that. However
all other threads are perfectly fine (JMX monitoring can connect to
it, i can get jstack thread dumps, etc etc)
The only thing that appers to be hanging is httpd.exe but even then
it's not hung in the sense that anything is blocked..
processexplorer/monitor show everything to be simply waiting for
requests that the windows tcp stack simply isn't passing to it.
Got all that, I suggested you stall it deliberately. Comment out
invocation of httpd.exe; then put a 20 minute 'sleep' in the installer
logic when it would typically query the browser.
While running the installer package, now try using httpd.exe with the
same config, etc outside of the installer entirely, and see if it
responds. This will indicate if there is something in the installer
that has messed up the network stack.
Aahh i see what you mean. I haven't done your exact reproduction, but I
have done similar cases where I have had separate httpd.exe processes
running on the same system.
Oh.
just typing that got me thinking. Our installer code does some really
skanky stuff, with simply a socket check to see if the port is
connectable. I wonder if it's possible it doesn't properly close the
socket. I've never run an httpd.exe on the same port in parallel to the
install.
You got me thinking of things to try now when I have time.
That said, if it is that easy to break AcceptEx, doesn't this seem like
a DoS just waiting to happen? Is Acceptex really that fragile?
