Alan Jenkins <[EMAIL PROTECTED]> wrote: > Juliusz Chroboczek wrote: > >> I found the following assert at io.c:281 was triggering:
> >> assert(*request->u.l.buf_location == NULL);
> > The assertion is guarded by
> >
> > if(request->buf == NULL)
> >
> > Now look at what happens in do_stream_buf (io.c line 111):
> >
> > return schedule_stream(operation, fd, offset,
> > NULL, 0, *buf_location, len,
> > NULL, 0, NULL, 0, buf_location,
> > handler, data);
> >
> > Here, connection->buf is set to *buf_location. If the assertion
> > triggers, then *buf_location was null at the time of the call, but
> > became non-null in the meantime.
> >
> > Race condition somewhere, kill me if I know where.
> Ah, I see now.
>
> You may well be able to reproduce this yourself. I'm using a mean test
> case that seems to stress polipo. I guess you're right and there's this
> one race condition (or class thereof) which can cause havok in several
> different ways.
>
> You may remember that I'm using Konqueror (3.5.9) as a browser. Firefox
> (3.0.1) doesn't seem to cause the same problems. To reproduce it I:
>
> 1. Open Google Groups
> 2. Open four threads in new tabs (middle click).
> 3. When the tabs have finished loading, quickly cycle through them,
> refreshing (F5) them all at the same time
> 4. Wait a bit. If nothing interesting happens, try repeating step 3 again.
>
> Here's the polipo output, from just refreshing four of these tabs. This
> is 1.0.4 with both of my patches, the one you approved of plus the
> workaround for the unknown race. So it survives, but it doesn't sound
> very happy!
>
> Established listening socket on port 8123.
> Restarting pipeline to groups.google.com:80.
> Restarting pipeline to groups.google.com:80.
> Couldn't send request to server: Immediate shutdown requested
> Couldn't send request to server: Immediate shutdown requested
> Restarting pipeline to groups.google.com:80.
> Couldn't send request to server: Immediate shutdown requested
> Couldn't send request to server: Immediate shutdown requested
> Couldn't send request to server: Immediate shutdown requested
> Couldn't send request to server: Immediate shutdown requested
> Restarting pipeline to groups.google.com:80.
> Restarting pipeline to groups.google.com:80.
> Couldn't send request to server: Immediate shutdown requested
> Restarting pipeline to groups.google.com:80.
> Couldn't send request to server: Immediate shutdown requested
> Restarting pipeline to groups.google.com:80.
> Restarting pipeline to groups.google.com:80.
> Aborting pipeline on groups.google.com:80.
> Couldn't send request to server: Immediate shutdown requested
> Restarting pipeline to groups.google.com:80.
> Couldn't send request to server: Immediate shutdown requested
I recently stumbled over a similar issue in polipo-20080524
(and 1.0.4 if I remember correctly):
[EMAIL PROTECTED] ~/test/polipo/polipo-20080524 $./polipo
socksParentProxy="10.0.0.2:9050" proxyAddress="10.0.0.1"
Disabling disk cache: No such file or directory
Disabling local tree: No such file or directory
Established listening socket on port 8123.
Couldn't parse ETag.
[...]
Couldn't parse ETag.
Couldn't parse ETag.
Restarting pipeline to images.slashdot.org:80.
Couldn't parse ETag.
Couldn't parse ETag.
Restarting pipeline to images.slashdot.org:80.
Restarting pipeline to images.slashdot.org:80.
Segmentation fault: 11 (core dumped)
[EMAIL PROTECTED] ~/test/polipo/polipo-20080524 $gdb polipo polipo.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `polipo'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0805ea2a in httpServerReplyHandler (status=0, event=0x8132280,
srequest=0x8132290) at server.c:1788
1788 assert(request->object->flags & OBJECT_INPROGRESS);
(gdb) where
#0 0x0805ea2a in httpServerReplyHandler (status=0, event=0x8132280,
srequest=0x8132290) at server.c:1788
#1 0x0804cecd in do_scheduled_stream (status=0, event=0x8132280) at io.c:368
#2 0x0804b4aa in eventLoop () at event.c:713
#3 0x08054409 in main (argc=3, argv=0xbfbfe9bc) at main.c:165
(gdb) f 0
#0 0x0805ea2a in httpServerReplyHandler (status=0, event=0x8132280,
srequest=0x8132290) at server.c:1788
1788 assert(request->object->flags & OBJECT_INPROGRESS);
(gdb) l
1783 HTTPRequestPtr request = connection->request;
1784 int i, body;
1785 int bufsize =
1786 (connection->flags & CONN_BIGBUF) ? bigBufferSize : CHUNK_SIZE;
1787
1788 assert(request->object->flags & OBJECT_INPROGRESS);
1789 if(status < 0) {
1790 if(connection->serviced >= 1) {
1791 httpServerRestart(connection);
1792 return 1;
(gdb) quit
I didn't have the time to look into it yet and can't reliably
reproduce it, but it seems to be triggered by multiple requests
for the same URL at roughly the same time.
Fabian
signature.asc
Description: PGP signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Polipo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/polipo-users
