Re: Polipo request times out; and polipo crashes

Fabian Keil <[email protected]>
Newsgroups gmane.comp.web.polipo.user
Message-ID <[email protected]>
David Röthlisberger <[email protected]> wrote:

> On 9 Nov 2012, at 01:05, Urs Holzer wrote:
> > I can confirm both issues on Linux x86_64 (by running Curl's test case 9 
> > against polipo from master branch).

I reproduced this (and other crashes) on FreeBSD amd64.

The attached patches 1 to 3 seem to prevent the crashes
for me, patch 4 is an unrelated bonus.

Curl's tests seem to show a couple of additional issues,
but I haven't analyzed them yet:

==8718== Syscall param write(buf) points to unaddressable byte(s)
==8718==    at 0x136F43A: __sys_write (write.S:3)
==8718==    by 0x136EEEF: __swrite (stdio.c:71)
==8718==    by 0x136EE3C: _swrite (stdio.c:133)
==8718==    by 0x136DCC0: __sfvwrite (fvwrite.c:89)
==8718==    by 0x136DBD9: fwrite (fwrite.c:95)
==8718==    by 0x40E6D7: really_do_log_n (log.c:476)
==8718==    by 0x425A33: httpWriteRequest (server.c:1620)
==8718==    by 0x42359C: httpServerTrigger (server.c:846)
==8718==    by 0x42268A: httpMakeServerRequest (server.c:475)
==8718==    by 0x425565: httpServerRequest (server.c:1509)
==8718==    by 0x41ECFF: httpClientNoticeRequest (client.c:1251)
==8718==    by 0x41DF4E: httpClientRequestContinue (client.c:946)
==8718==  Address 0xca000 is not stack'd, malloc'd or (recently) free'd
[...]
==8718== 38 bytes in 2 blocks are definitely lost in loss record 101 of 297
==8718==    at 0x104B33B: malloc (vg_replace_malloc.c:266)
==8718==    by 0x402A1C: strdup_n (util.c:30)
==8718==    by 0x42DD1F: httpParseHeaders (http_parse.c:1037)
==8718==    by 0x4268BB: httpServerHandlerHeaders (server.c:1931)
==8718==    by 0x426364: httpServerReplyHandler (server.c:1818)
==8718==    by 0x40724F: do_scheduled_stream (io.c:366)
==8718==    by 0x405DD4: eventLoop (event.c:718)
==8718==    by 0x414F39: main (main.c:165)
==8718== 
==8718== 658 bytes in 14 blocks are definitely lost in loss record 290 of 297
==8718==    at 0x104B33B: malloc (vg_replace_malloc.c:266)
==8718==    by 0x405F87: conditionWait (event.c:760)
==8718==    by 0x423FA5: httpServerDoSide (server.c:1040)
==8718==    by 0x42436B: httpServerSideHandlerCommon (server.c:1132)
==8718==    by 0x4243D7: httpServerSideHandler2 (server.c:1149)
==8718==    by 0x40724F: do_scheduled_stream (io.c:366)
==8718==    by 0x406952: schedule_stream (io.c:205)
==8718==    by 0x406426: do_stream_2 (io.c:81)
==8718==    by 0x423DB4: httpServerDoSide (server.c:1002)
==8718==    by 0x423C0C: httpServerSideRequest (server.c:975)
==8718==    by 0x423444: httpServerTrigger (server.c:800)
==8718==    by 0x422DFB: httpServerConnectionHandlerCommon (server.c:647)
==8718== 
==8718== 2,520 bytes in 21 blocks are definitely lost in loss record 293 of 297
==8718==    at 0x104B33B: malloc (vg_replace_malloc.c:266)
==8718==    by 0x41A571: httpMakeConnection (http.c:557)
==8718==    by 0x41BEC9: httpAccept (client.c:95)
==8718==    by 0x407F5F: do_scheduled_accept (io.c:677)
==8718==    by 0x405DD4: eventLoop (event.c:718)
==8718==    by 0x414F39: main (main.c:165)
==8718== 
==8718== 3,084 (2,400 direct, 684 indirect) bytes in 12 blocks are definitely lost in loss record 295 of 297
==8718==    at 0x104B33B: malloc (vg_replace_malloc.c:266)
==8718==    by 0x40B2A5: makeObject (object.c:193)
==8718==    by 0x41DE13: httpClientRequestContinue (client.c:909)
==8718==    by 0x434D8F: urlForbidden (forbidden.c:482)
==8718==    by 0x41DA86: httpClientRequest (client.c:824)
==8718==    by 0x41D3A7: httpClientHandlerHeaders (client.c:666)
==8718==    by 0x41C9BB: httpClientHandler (client.c:392)
==8718==    by 0x40724F: do_scheduled_stream (io.c:366)
==8718==    by 0x405DD4: eventLoop (event.c:718)
==8718==    by 0x414F39: main (main.c:165)

> I have a meta-comment regarding your use of curl's test suite:
> 
> It would be great if you can automate the running of curl's test suite
> (or a subset of it) through polipo so that it can be run with "make
> check" from the polipo source directory. Perhaps use an environment
> variable to specify the location of the curl source files (or an
> environment variable to specify a tag or URL of the curl source code to
> checkout into a temporary directory).

I've been using curl's test framework for a couple of years now
to test Privoxy and intend to upstream my modifications in the
near future after some more polishing.

Once that's done, using the tests with Polipo should be more
convenient as well.

> An easy way to share that work would be to fork polipo on github and
> commit to a branch on your fork, then post the link here. I'd help out
> when I can (for example with diagnosing failing tests; I expect a lot of
> them will fail, but not always due to a fault of polipo's).

You expect correctly:
TESTDONE: 35 tests out of 249 reported OK: 14%

Only executing the HTTP tests that are already known to work with Privoxy:
TESTDONE: 34 tests out of 211 reported OK: 16%

To be clear, this is not a fair comparison because I already
patched runtests.pl to prevent false positives when using Privoxy
but haven't patched it to deal with false positives when using
Polipo (yet).

Fabian

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

_______________________________________________
Polipo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/polipo-users
0001-Fix-a-segmentation-fault-that-was-reproducible-with-.patch (text/x-patch, 977 B)
From d566738e60087307168756dd53fba703469a6f56 Mon Sep 17 00:00:00 2001
From: Fabian Keil <[email protected]>
Date: Wed, 14 Nov 2012 21:40:31 +0100
Subject: [PATCH 1/4] Fix a segmentation fault that was reproducible with
 curl's test #9
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The issue was previously reported by Ming Fu and David Röthlisberger.
---
 server.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/server.c b/server.c
index 408b910..6d0e972 100644
--- a/server.c
+++ b/server.c
@@ -1153,7 +1153,8 @@ httpServerContinueConditionHandler(int status, ConditionHandlerPtr chandler)
 {
     HTTPConnectionPtr connection = *(HTTPConnectionPtr*)chandler->data;
 
-    if(connection->request->flags & REQUEST_WAIT_CONTINUE)
+    if(!connection->request ||
+       connection->request->flags & REQUEST_WAIT_CONTINUE)
         return 0;
     httpServerDelayedDoSide(connection);
     return 1;
-- 
1.8.0
0002-Stop-asserting-that-released-objects-have-no-conditi.patch (text/x-patch, 1.2 KB)
From e7b6ba4c326243ca1eeeb5251646c6a2546b7c86 Mon Sep 17 00:00:00 2001
From: Fabian Keil <[email protected]>
Date: Wed, 14 Nov 2012 22:07:11 +0100
Subject: [PATCH 2/4] Stop asserting that released objects have no condition
 handlers

The assertions were reproducible triggered by curl's test 9.
---
 object.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/object.c b/object.c
index ee5350f..4ab8c9e 100644
--- a/object.c
+++ b/object.c
@@ -288,8 +288,7 @@ releaseObject(ObjectPtr object)
            (unsigned long)object, object->refcount);
     object->refcount--;
     if(object->refcount == 0) {
-        assert(!object->condition.handlers && 
-               !(object->flags & OBJECT_INPROGRESS));
+        assert(!(object->flags & OBJECT_INPROGRESS));
         if(!(object->flags & OBJECT_PUBLIC))
             destroyObject(object);
     }
@@ -642,8 +641,7 @@ destroyObject(ObjectPtr object)
     int i;
 
     assert(object->refcount == 0 && !object->requestor);
-    assert(!object->condition.handlers && 
-           (object->flags & OBJECT_INPROGRESS) == 0);
+    assert((object->flags & OBJECT_INPROGRESS) == 0);
 
     if(object->disk_entry)
         destroyDiskEntry(object, 0);
-- 
1.8.0
0003-Do-not-call-httpServerDoSide-from-httpClientDelayedD.patch (text/x-patch, 778 B)
From 9b402037ad46dcf4d4c6886dfb5208c12f324509 Mon Sep 17 00:00:00 2001
From: Fabian Keil <[email protected]>
Date: Wed, 14 Nov 2012 22:30:46 +0100
Subject: [PATCH 3/4] Do not call httpServerDoSide() from
 httpClientDelayedDoSideHandler() with a NULL request

Prevents a segfault reproducible with curl's test 1129.
---
 server.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/server.c b/server.c
index 6d0e972..73bee95 100644
--- a/server.c
+++ b/server.c
@@ -1060,7 +1060,8 @@ static int
 httpClientDelayedDoSideHandler(TimeEventHandlerPtr event)
 {
     HTTPConnectionPtr connection = *(HTTPConnectionPtr*)event->data;
-    httpServerDoSide(connection);
+    if (connection->request)
+        httpServerDoSide(connection);
     return 1;
 }
 
-- 
1.8.0
0004-Fix-a-couple-of-memory-leaks-in-httpParseHeaders.patch (text/x-patch, 1 KB)
From 5fecfadccd54e6ee83ff68f1531e78b6a4d2e735 Mon Sep 17 00:00:00 2001
From: Fabian Keil <[email protected]>
Date: Wed, 14 Nov 2012 23:30:52 +0100
Subject: [PATCH 4/4] Fix a couple of memory leaks in httpParseHeaders()

---
 http_parse.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/http_parse.c b/http_parse.c
index a5940ff..b0a6a9d 100644
--- a/http_parse.c
+++ b/http_parse.c
@@ -1306,6 +1306,7 @@ httpParseHeaders(int client, AtomPtr url,
                 do_log(L_ERROR, "Couldn't allocate condition.\n");
                 if(im) free(im);
                 if(inm) free(inm);
+                if(ifrange) free(ifrange);
             }
         } else {
             condition = NULL;
@@ -1362,6 +1363,9 @@ httpParseHeaders(int client, AtomPtr url,
     if(hbuf && hbuf != hbuf_small) free(hbuf);
     if(name) releaseAtom(name);
     if(etag) free(etag);
+    if(im) free(im);
+    if(inm) free(inm);
+    if(ifrange) free(ifrange);
     if(location) free(location);
     if(via) releaseAtom(via);
     if(expect) releaseAtom(expect);
-- 
1.8.0
signature.asc (application/pgp-signature, 196 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlCk1G4ACgkQBYqIVf93VJ2MWwCdHR5FArsW6h0YH//xaCNfaXWL
agQAn1kMnoZJ9pUxHy6bTpa9gOjU8U9R
=Ib3i
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.