You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2012/04/11 01:13:36 UTC
ra_serf crashes on Windows with AVG 2012 Surf-Shield
I first noticed this during testing of 1.7.4, and now reproduced it
with trunk, both with serf 1.0.0 and 1.0.3: when running the testsuite
over serf, on Windows XP with "AVG Anti-virus Free Edition 2012" [1]
enabled, I get a lot of crashes and also a couple of infinite loops.
It's probably not a new problem since 1.7.4, but new since AVG 2012
(1.7.4 is probably the first time in 2012 that I ran the testsuite
over ra_serf).
I narrowed it down to the AVG option "Surf-Shield" (part of
"LinkScanner"). If I disable "Surf-Shield", the testsuite completes
normally over ra_serf. The other ra_* methods don't have a problem
with AVG Surf-Shield.
I don't know what Surf-Shield does. Its description says: "Can detect
exploit sites and other complex online threats". There is some more
explanation on the AVG website, but it's still pretty vague [2]. Maybe
it does some throttling of requests/responses, inspecting things or
so, ... but whatever it does, svn+serf should probably not crash or
hang. I'm guessing AVG is used by a significant percentage of
non-corporate Windows users (and Surf-Shield is enabled by default in
the Free Edition 2012). I'm not sure if the fact that the server runs
on localhost (and thus with very fast access) is part of the equation.
Here are some of the tests that crash (I don't let the entire
testsuite run to completion, because some tests really hang, and I
have to kill the svn.exe process to have the testsuite continue (which
gets tedious after a while :-))):
authz_tests.py 4, 5, 7, 10, 15, 16
basic_tests.py 6, 21, 31, 59
blame_tests.py 10
...
These really hang (one cpu core fully occupied by svn.exe, memory
usage continuously increasing a bit (a couple of KB's per second); I
can only continue after killing the svn.exe process):
authz_tests.py 14
blame_tests.py 3
This one just fails, I think:
authz_tests.py 23
Most of the crashes are similar, crashing somewhere inside
svn_ra_serf__get_mergeinfo(). But there are also a couple of others.
In attachment the dav-tests.log of all tests until I had enough of it,
and also the crash dump file of the first crash. If necessary I can
send the others too.
If there is anything I can do to provide more info, or try other
things, let me know ...
Maybe someone else on Windows can try to reproduce this, by installing
AVG Free Edition 2012? Would be interesting to know at least if it's
not a local problem for my machine, or something specific to XP ...
--
Johan
[1] http://www.avg.com
[2] http://www.avg.com/eu-en/linkscanner
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Apr 11, 2012 at 1:24 AM, Daniel Shahaf <da...@elego.de> wrote:
> Johan Corveleyn wrote on Wed, Apr 11, 2012 at 01:13:36 +0200:
>> If there is anything I can do to provide more info, or try other
>> things, let me know ...
>
> Does it depend on the FS backend in use?
Can't test that right now (I have only FSFS compiled on my local
setup). But it's a client-side crash, so I suppose it shouldn't really
matter. Maybe someone who has BDB built on Windows can verify this?
Here are the server-side logs by the way. I don't see anything special
in them, except things that are probably expected by the
testsuite-run.
--
Johan
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Daniel Shahaf <da...@elego.de>.
Johan Corveleyn wrote on Wed, Apr 11, 2012 at 01:13:36 +0200:
> If there is anything I can do to provide more info, or try other
> things, let me know ...
Does it depend on the FS backend in use?
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Greg Stein <gs...@gmail.com>.
On Tue, May 8, 2012 at 3:19 AM, Lieven Govaerts <sv...@mobsol.be> wrote:
> On Tue, May 8, 2012 at 2:29 AM, Greg Stein <gs...@gmail.com> wrote:
>...
>> My intent is to replace the code you quoted with something basically
>> like: handler->server_error = alloc(). The core response handler will
>> then start processing the body as an error.
>
> So you mark the request as done as soon as the 404 is recognized, but then
> add an extra reminder for ra_serf to continue processing the response until
> read completely. That's better than what I suggested before.
Not quite. The "done" flag needs to wait until the entire response has
been consumed. Otherwise, we might not reenter serf_context_run() to
actually finish the thing off.
I guess there *is* the possibility to let the upper level continue
immediately, and *if* the context is run again, then we consume the
remaining response before dealing with further responses. RIght now...
not trying to deal with that. My hope is to just build in all "done"
processing into the core handling and wait for the response EOF. (not
just when the semantics seem to indicate done-ness)
>> There are a couple similar cases. I'm looking at them now to ensure
>> the errors these things raise will propagate correctly, or to place
>> the error creation elsewhere. It should be fixed within a few days
>> (traveling tmw).
>
> Nice. I'll keep my windows vm uptodate, I'll see if I can find some time
> next week to test your changes.
Cool. Thanks!
Cheers,
-g
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Tue, May 8, 2012 at 2:29 AM, Greg Stein <gs...@gmail.com> wrote:
> On May 7, 2012 8:16 PM, "Lieven Govaerts" <sv...@mobsol.be> wrote:
> >...
> > The problem is in ra_serf/util.c svn_ra_serf__handle_xml_parser:
> >
> > if (sl.code == 404 && ctx->ignore_errors == FALSE)
> > {
> > add_done_item(ctx);
> >
> > err = svn_ra_serf__handle_server_error(request, response, pool);
> >
> > SVN_ERR(svn_error_compose_create(
> > svn_ra_serf__handle_discard_body(request, response, NULL, pool),
> > err));
> >
> > When the response status of a PROPFIND request is 404, you see that the
> response body is discarded with calls to svn_ra_serf__handle_server_error
> and svn_ra_serf__handle_server_error.
> >
> > In your particular scenario, the status line of the response is already
> received, but the body is not. Reading from the response buckets returns
> EAGAIN status.
> > Problem: the add_done_item(ctx) line ensures that the request is
> considered as handled, while the response body is still waiting on the
> socket to be read. ra_serf will only run the serf loop again with the next
> request. If the connection is not closed directly, which here it isn't, the
> next request will have a response that doesn't match.
>
> Thanks for the excellent analysis of what Johan was running into.
>
> > The fix is to ensure that the request is only marked as handled when a.
> the response body has been discarded completely or a b. read error was
> encountered resulting in serf setting up a new connection. I don't have a
> tested solution, as my Windows vm was so nice to reboot to install some
> updates while I was in the middle of a debug session, and I don't have time
> now to start over.
>
> Not to worry. I've been working on exactly that stuff. In fact, the
> code you quoted is one of my targets to fix.
> svn_ra_serf__handle_server_error() is conceptually broken (and needs
> to be removed for the reason you state), as I noted in the log message
> of r1335217.
>
> My intent is to replace the code you quoted with something basically
> like: handler->server_error = alloc(). The core response handler will
> then start processing the body as an error.
>
So you mark the request as done as soon as the 404 is recognized, but then
add an extra reminder for ra_serf to continue processing the response until
read completely. That's better than what I suggested before.
There are a couple similar cases. I'm looking at them now to ensure
> the errors these things raise will propagate correctly, or to place
> the error creation elsewhere. It should be fixed within a few days
> (traveling tmw).
>
Nice. I'll keep my windows vm uptodate, I'll see if I can find some time
next week to test your changes.
Cheers,
> -g
>
Lieven
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Greg Stein <gs...@gmail.com>.
On Tue, May 8, 2012 at 3:59 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>...
> Though this issue also hits 1.7, it doesn't seem like this is
> something that can be backported easily (with all the recent changes
> to ra_serf), does it? Unless a specific ("quick") fix is made for 1.7?
A backport won't be possible. There are too many (unrelated) changes
mixed in with the overall network/response processing going on.
I'm not sure that a quick fix is possible :-( ... the broken part is
working synchronously, when the solution is asynchronous. That changes
the code flow quite a bit.
>...
Cheers,
-g
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, May 8, 2012 at 2:29 AM, Greg Stein <gs...@gmail.com> wrote:
> On May 7, 2012 8:16 PM, "Lieven Govaerts" <sv...@mobsol.be> wrote:
>>...
>> The problem is in ra_serf/util.c svn_ra_serf__handle_xml_parser:
>>
>> if (sl.code == 404 && ctx->ignore_errors == FALSE)
>> {
>> add_done_item(ctx);
>>
>> err = svn_ra_serf__handle_server_error(request, response, pool);
>>
>> SVN_ERR(svn_error_compose_create(
>> svn_ra_serf__handle_discard_body(request, response, NULL, pool),
>> err));
>>
>> When the response status of a PROPFIND request is 404, you see that the response body is discarded with calls to svn_ra_serf__handle_server_error and svn_ra_serf__handle_server_error.
>>
>> In your particular scenario, the status line of the response is already received, but the body is not. Reading from the response buckets returns EAGAIN status.
>> Problem: the add_done_item(ctx) line ensures that the request is considered as handled, while the response body is still waiting on the socket to be read. ra_serf will only run the serf loop again with the next request. If the connection is not closed directly, which here it isn't, the next request will have a response that doesn't match.
>
> Thanks for the excellent analysis of what Johan was running into.
>
>> The fix is to ensure that the request is only marked as handled when a. the response body has been discarded completely or a b. read error was encountered resulting in serf setting up a new connection. I don't have a tested solution, as my Windows vm was so nice to reboot to install some updates while I was in the middle of a debug session, and I don't have time now to start over.
>
> Not to worry. I've been working on exactly that stuff. In fact, the
> code you quoted is one of my targets to fix.
Thanks for looking into this, guys. Let me know if you'd like me to
run tests or something like that ...
Though this issue also hits 1.7, it doesn't seem like this is
something that can be backported easily (with all the recent changes
to ra_serf), does it? Unless a specific ("quick") fix is made for 1.7?
Anyway, I'm not going to push this. Serf is not the default in 1.7,
and the combination with AVG (Windows) is probably non existant at the
moment (there haven't been any user reports), so it's probably not
worth the effort.
--
Johan
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Greg Stein <gs...@gmail.com>.
On May 7, 2012 8:16 PM, "Lieven Govaerts" <sv...@mobsol.be> wrote:
>...
> The problem is in ra_serf/util.c svn_ra_serf__handle_xml_parser:
>
> if (sl.code == 404 && ctx->ignore_errors == FALSE)
> {
> add_done_item(ctx);
>
> err = svn_ra_serf__handle_server_error(request, response, pool);
>
> SVN_ERR(svn_error_compose_create(
> svn_ra_serf__handle_discard_body(request, response, NULL, pool),
> err));
>
> When the response status of a PROPFIND request is 404, you see that the response body is discarded with calls to svn_ra_serf__handle_server_error and svn_ra_serf__handle_server_error.
>
> In your particular scenario, the status line of the response is already received, but the body is not. Reading from the response buckets returns EAGAIN status.
> Problem: the add_done_item(ctx) line ensures that the request is considered as handled, while the response body is still waiting on the socket to be read. ra_serf will only run the serf loop again with the next request. If the connection is not closed directly, which here it isn't, the next request will have a response that doesn't match.
Thanks for the excellent analysis of what Johan was running into.
> The fix is to ensure that the request is only marked as handled when a. the response body has been discarded completely or a b. read error was encountered resulting in serf setting up a new connection. I don't have a tested solution, as my Windows vm was so nice to reboot to install some updates while I was in the middle of a debug session, and I don't have time now to start over.
Not to worry. I've been working on exactly that stuff. In fact, the
code you quoted is one of my targets to fix.
svn_ra_serf__handle_server_error() is conceptually broken (and needs
to be removed for the reason you state), as I noted in the log message
of r1335217.
My intent is to replace the code you quoted with something basically
like: handler->server_error = alloc(). The core response handler will
then start processing the body as an error.
There are a couple similar cases. I'm looking at them now to ensure
the errors these things raise will propagate correctly, or to place
the error creation elsewhere. It should be fixed within a few days
(traveling tmw).
Cheers,
-g
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Lieven Govaerts <sv...@mobsol.be>.
Johan,
On Sat, Apr 14, 2012 at 11:42 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 1:43 PM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> > On Wed, Apr 11, 2012 at 12:28 PM, Philip Martin
> > <ph...@wandisco.com> wrote:
> >> Johan Corveleyn <jc...@gmail.com> writes:
> >>
> >>> I don't know what Surf-Shield does. Its description says: "Can detect
> >>> exploit sites and other complex online threats". There is some more
> >>> explanation on the AVG website, but it's still pretty vague [2]. Maybe
> >>> it does some throttling of requests/responses, inspecting things or
> >>> so, ... but whatever it does, svn+serf should probably not crash or
> >>> hang.
> >>
> >> You could compare the apache logs with/without Surf-Shield.
> >> You could
> >> capture the traffic with/without Surf-Shield and compare.
>
> Ok, I picked the first failing test, authz_tests.py#4, and executed
> that with and without Surf-Shield. Please find in attachment two zip
> files of those two runs, containing Apache logs and a wire capture, as
> well as the crash dump file.
>
> I don't see a difference in the Apache logs (they are identical,
> except that the crashing one stops earlier). The wire capture ... I'm
> not sure. The one from the crash is obviously smaller. But when I
> "follow TCP stream" they both seem identical (same number of bytes and
> all), and when I then filter out the followed stream, nothing remains.
> So I'm not sure where the difference is ...
>
> I'm hoping someone can take it from here. I'm not familiar with this
> part of the code. Maybe the best place to start digging is the crash
> dump (and/or a more thorough analysis of both wire captures). If I
> hear nothing in the next couple of days, I'll put this into the issue
> tracker so it isn't forgotten.
>
>
The dump & logs don't show the issue, only debugging helps in this case.
The problem is in ra_serf/util.c svn_ra_serf__handle_xml_parser:
if (sl.code == 404 && ctx->ignore_errors == FALSE)
{
add_done_item(ctx);
err = svn_ra_serf__handle_server_error(request, response, pool);
SVN_ERR(svn_error_compose_create(
svn_ra_serf__handle_discard_body(request, response, NULL, pool),
err));
When the response status of a PROPFIND request is 404, you see that the
response body is discarded with calls to svn_ra_serf__handle_server_error
and svn_ra_serf__handle_server_error.
In your particular scenario, the status line of the response is already
received, but the body is not. Reading from the response buckets returns
EAGAIN status.
Problem: the add_done_item(ctx) line ensures that the request is considered
as handled, while the response body is still waiting on the socket to be
read. ra_serf will only run the serf loop again with the next request. If
the connection is not closed directly, which here it isn't, the next
request will have a response that doesn't match.
The fix is to ensure that the request is only marked as handled when a. the
response body has been discarded completely or a b. read error was
encountered resulting in serf setting up a new connection. I don't have a
tested solution, as my Windows vm was so nice to reboot to install some
updates while I was in the middle of a debug session, and I don't have time
now to start over.
hth,
Lieven
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Apr 14, 2012 at 11:42 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 1:43 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Wed, Apr 11, 2012 at 12:28 PM, Philip Martin
>> <ph...@wandisco.com> wrote:
>>> Johan Corveleyn <jc...@gmail.com> writes:
>>>
>>>> I don't know what Surf-Shield does. Its description says: "Can detect
>>>> exploit sites and other complex online threats". There is some more
>>>> explanation on the AVG website, but it's still pretty vague [2]. Maybe
>>>> it does some throttling of requests/responses, inspecting things or
>>>> so, ... but whatever it does, svn+serf should probably not crash or
>>>> hang.
>>>
>>> You could compare the apache logs with/without Surf-Shield.
>>> You could
>>> capture the traffic with/without Surf-Shield and compare.
>
> Ok, I picked the first failing test, authz_tests.py#4, and executed
> that with and without Surf-Shield. Please find in attachment two zip
> files of those two runs, containing Apache logs and a wire capture, as
> well as the crash dump file.
>
> I don't see a difference in the Apache logs (they are identical,
> except that the crashing one stops earlier). The wire capture ... I'm
> not sure. The one from the crash is obviously smaller. But when I
> "follow TCP stream" they both seem identical (same number of bytes and
> all), and when I then filter out the followed stream, nothing remains.
> So I'm not sure where the difference is ...
>
> I'm hoping someone can take it from here. I'm not familiar with this
> part of the code. Maybe the best place to start digging is the crash
> dump (and/or a more thorough analysis of both wire captures). If I
> hear nothing in the next couple of days, I'll put this into the issue
> tracker so it isn't forgotten.
Ok, I finally made an issue out of this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4175
--
Johan
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Apr 11, 2012 at 1:43 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 12:28 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Johan Corveleyn <jc...@gmail.com> writes:
>>
>>> I don't know what Surf-Shield does. Its description says: "Can detect
>>> exploit sites and other complex online threats". There is some more
>>> explanation on the AVG website, but it's still pretty vague [2]. Maybe
>>> it does some throttling of requests/responses, inspecting things or
>>> so, ... but whatever it does, svn+serf should probably not crash or
>>> hang.
>>
>> You could compare the apache logs with/without Surf-Shield.
>> You could
>> capture the traffic with/without Surf-Shield and compare.
Ok, I picked the first failing test, authz_tests.py#4, and executed
that with and without Surf-Shield. Please find in attachment two zip
files of those two runs, containing Apache logs and a wire capture, as
well as the crash dump file.
I don't see a difference in the Apache logs (they are identical,
except that the crashing one stops earlier). The wire capture ... I'm
not sure. The one from the crash is obviously smaller. But when I
"follow TCP stream" they both seem identical (same number of bytes and
all), and when I then filter out the followed stream, nothing remains.
So I'm not sure where the difference is ...
I'm hoping someone can take it from here. I'm not familiar with this
part of the code. Maybe the best place to start digging is the crash
dump (and/or a more thorough analysis of both wire captures). If I
hear nothing in the next couple of days, I'll put this into the issue
tracker so it isn't forgotten.
>> Which version
>> of Apache are you using?
>
> 2.2.19
>
>> Which MPM?
>
> That would be the default on Win XP, which is mpm_winnt. [3]
>
--
Johan
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> Maybe the easiest thing to do is to set up Apache on a second machine,
> so I don't have to go over the loopback device ...
You would have to mount the test directory on both machines. The client
side is responsible for repository creation, the server side is
responsible for repository modification.
--
Philip
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Wed, Apr 11, 2012 at 15:46:38 +0200:
> On 11.04.2012 13:52, Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Wed, Apr 11, 2012 at 13:43:57 +0200:
> >> If anyone has any suggestions on capturing network traffic on
> >> localhost on Windows XP ... I'm all ears.
> >>
> >> Maybe the easiest thing to do is to set up Apache on a second machine,
> >> so I don't have to go over the loopback device ...
> >>
> > One option: don't use the loopback device, use some other interface.
> >
> > That is, have httpd listen on 0.0.0.0 and pass --url=http://192.168.9.199
> > to foo_tests.py, where 192.168.9.199 is your externally-visible
> > IP address.
>
> The traffic will still get routed through the loopback device if it's on
> the same machine. At least I hope so, though could be that Microsoft has
> another "enhancement" in their TCP stack in this regard.
>
> brane@zulu:~$ ifconfig en0
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=27<RXCSUM,TXCSUM,VLAN_MTU,TSO4>
> ether 34:15:9e:03:09:74
> inet6 fe80::3615:9eff:fe03:974%en0 prefixlen 64 scopeid 0x4
> inet 172.23.17.71 netmask 0xffffff00 broadcast 172.23.17.255
> media: autoselect (1000baseT <full-duplex,flow-control>)
> status: active
> brane@zulu:~$ route get 172.23.17.71
> route to: 172.23.17.71
> destination: 172.23.17.71
> interface: lo0
> flags: <UP,HOST,DONE,STATIC>
> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
> 49152 49152 0 0 0 0 16384 0
>
Good point. To avoid this I assume Johan could explicitly set the route
for 172.23.17.71 to be a local router, or do the Windows equivalent of
'ifconfig lo0 down'.
> -- Brane
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Branko Čibej <br...@apache.org>.
On 11.04.2012 13:52, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Wed, Apr 11, 2012 at 13:43:57 +0200:
>> If anyone has any suggestions on capturing network traffic on
>> localhost on Windows XP ... I'm all ears.
>>
>> Maybe the easiest thing to do is to set up Apache on a second machine,
>> so I don't have to go over the loopback device ...
>>
> One option: don't use the loopback device, use some other interface.
>
> That is, have httpd listen on 0.0.0.0 and pass --url=http://192.168.9.199
> to foo_tests.py, where 192.168.9.199 is your externally-visible
> IP address.
The traffic will still get routed through the loopback device if it's on
the same machine. At least I hope so, though could be that Microsoft has
another "enhancement" in their TCP stack in this regard.
brane@zulu:~$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=27<RXCSUM,TXCSUM,VLAN_MTU,TSO4>
ether 34:15:9e:03:09:74
inet6 fe80::3615:9eff:fe03:974%en0 prefixlen 64 scopeid 0x4
inet 172.23.17.71 netmask 0xffffff00 broadcast 172.23.17.255
media: autoselect (1000baseT <full-duplex,flow-control>)
status: active
brane@zulu:~$ route get 172.23.17.71
route to: 172.23.17.71
destination: 172.23.17.71
interface: lo0
flags: <UP,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
49152 49152 0 0 0 0 16384 0
-- Brane
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Daniel Shahaf <da...@elego.de>.
Johan Corveleyn wrote on Wed, Apr 11, 2012 at 13:43:57 +0200:
> If anyone has any suggestions on capturing network traffic on
> localhost on Windows XP ... I'm all ears.
>
> Maybe the easiest thing to do is to set up Apache on a second machine,
> so I don't have to go over the loopback device ...
>
One option: don't use the loopback device, use some other interface.
That is, have httpd listen on 0.0.0.0 and pass --url=http://192.168.9.199
to foo_tests.py, where 192.168.9.199 is your externally-visible
IP address.
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Apr 11, 2012 at 12:28 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Johan Corveleyn <jc...@gmail.com> writes:
>
>> I don't know what Surf-Shield does. Its description says: "Can detect
>> exploit sites and other complex online threats". There is some more
>> explanation on the AVG website, but it's still pretty vague [2]. Maybe
>> it does some throttling of requests/responses, inspecting things or
>> so, ... but whatever it does, svn+serf should probably not crash or
>> hang.
>
> You could compare the apache logs with/without Surf-Shield.
Ok, I'll try to do that tonight.
> You could
> capture the traffic with/without Surf-Shield and compare.
That might be difficult to do on my machine. I remember I had trouble
to capture network traffic on the loopback device. Tried with
WireShark, but I haven't gotten it to work.
See also the WireShark Wiki [1] ("You can't capture on the local
loopback address 127.0.0.1 with a Windows packet capture driver like
WinPcap."). I also tried the suggested RawCap [2], but that didn't
work either (its homepage says under "Raw Sockets Limitations": When
sniffing from localhost in Windows XP you will only be able to capture
UDP and ICMP traffic, and not TCP).
If anyone has any suggestions on capturing network traffic on
localhost on Windows XP ... I'm all ears.
Maybe the easiest thing to do is to set up Apache on a second machine,
so I don't have to go over the loopback device ...
> Which version
> of Apache are you using?
2.2.19
> Which MPM?
That would be the default on Win XP, which is mpm_winnt. [3]
--
Johan
[1] http://wiki.wireshark.org/CaptureSetup/Loopback
[2] http://www.netresec.com/?page=RawCap
[3] http://httpd.apache.org/docs/2.2/mod/mpm_winnt.html
Re: ra_serf crashes on Windows with AVG 2012 Surf-Shield
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> I don't know what Surf-Shield does. Its description says: "Can detect
> exploit sites and other complex online threats". There is some more
> explanation on the AVG website, but it's still pretty vague [2]. Maybe
> it does some throttling of requests/responses, inspecting things or
> so, ... but whatever it does, svn+serf should probably not crash or
> hang.
You could compare the apache logs with/without Surf-Shield. You could
capture the traffic with/without Surf-Shield and compare. Which version
of Apache are you using? Which MPM?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com