On 03/14/2014 05:40 PM, Aleksandar Kuktin wrote:
> For the record, I haven't forgotten about the patch I said I would look
> into, but I have very little time in which to do it.
>
> I had a crash with polipo-20140107 while browsing http://9gag.com/ .
>
> The extract from the system log, showing all the messages from this
> particular instance of polipo, has been attached.
>
> The kernel message is thus:
> segfault at bf3e0ffc ip 080571fd sp bf3e1000 error 6 in
> polipo[8048000+2a000]
>
> The below is the disassembly of the relevant portion of the binary:
>
> 080571f8 <httpCondition>:
> httpCondition():
> /home/ak/hack/rad/polipo-20140107-new/http.c:814
>   80571f8:       55                      push   %ebp
>   80571f9:       89 e5                   mov    %esp,%ebp
>   80571fb:       57                      push   %edi
>   80571fc:       56                      push   %esi
>   80571fd:       53                      push   %ebx
>   80571fe:       83 ec 0c                sub    $0xc,%esp
>   8057201:       8b 7d 08                mov    0x8(%ebp),%edi
>   8057204:       8b 5d 0c                mov    0xc(%ebp),%ebx
> /home/ak/hack/rad/polipo-20140107-new/http.c:817
>   8057207:       f6 47 12 02             testb  $0x2,0x12(%edi)
>   805720b:       74 19                   je     8057226 <httpCondition+0x2e>
>   805720d:       68 c6 d5 06 08          push   $0x806d5c6
>   8057212:       68 31 03 00 00          push   $0x331
>   8057217:       68 da ca 06 08          push   $0x806cada
>   805721c:       68 03 cf 06 08          push   $0x806cf03
>   8057221:       e8 12 24 ff ff          call   8049638
>   <__assert_fail@plt>
> /home/ak/hack/rad/polipo-20140107-new/http.c:819
>   8057226:       85 db                   test   %ebx,%ebx
>   8057228:       74 71                   je     805729b <httpCondition+0xa3>
> /home/ak/hack/rad/polipo-20140107-new/http.c:821
>   805722a:       8b 13                   mov    (%ebx),%edx
>   805722c:       31 f6                   xor    %esi,%esi
>   805722e:       85 d2                   test   %edx,%edx
>   8057230:       78 0f                   js     8057241 <httpCondition+0x49>
>
> The core dump has not been generated.
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> Polipo-users mailing list
> Polipo-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/polipo-users
>

I'm also getting frequent crashes.
With debians 1.1.1 version...

The first one was this:

The kernel message I got:
[1118160.309050] polipo[491]: segfault at bf5cdff8 ip 0804f634 sp 
bf5cdffc error 6 in polipo[8048000+2e000]

But often it crashes and I do not get an error message at all.
I have not been able to reproduce it in gdb. It does happen about once a 
day...

objdump -d `which polipo` gives:
[...]
  804f60e:       00 00 00
  804f611:       c7 05 c0 73 07 08 00    movl   $0x0,0x80773c0
  804f618:       00 00 00
  804f61b:       8d 65 f4                lea    -0xc(%ebp),%esp
  804f61e:       b8 01 00 00 00          mov    $0x1,%eax
  804f623:       5b                      pop    %ebx
  804f624:       5e                      pop    %esi
  804f625:       5f                      pop    %edi
  804f626:       5d                      pop    %ebp
  804f627:       c3                      ret
  804f628:       55                      push   %ebp
  804f629:       89 e5                   mov    %esp,%ebp
  804f62b:       57                      push   %edi
  804f62c:       56                      push   %esi
  804f62d:       53                      push   %ebx
  804f62e:       83 ec 10                sub    $0x10,%esp
  804f631:       8b 75 0c                mov    0xc(%ebp),%esi
_804f634:_      ff 75 10                pushl  0x10(%ebp)
  804f637:       56                      push   %esi
  804f638:       ff 75 08                pushl  0x8(%ebp)
  804f63b:       e8 87 f0 ff ff          call   804e6c7 <calloc@plt+0x4d07>
  804f640:       83 c4 10                add    $0x10,%esp
  804f643:       85 c0                   test   %eax,%eax
  804f645:       74 19                   je     804f660 <calloc@plt+0x5ca0>
  804f647:       83 7d 14 00             cmpl   $0x0,0x14(%ebp)
  804f64b:       89 c2                   mov    %eax,%edx
  804f64d:       0f 85 8f 02 00 00       jne    804f8e2 <calloc@plt+0x5f22>
  804f653:       52                      push   %edx
  804f654:       52                      push   %edx
  804f655:       6a 00                   push   $0x0
  804f657:       50                      push   %eax
[...]

Is the stack too small?

The debian packages us stripped binaries by default, so I
rebuild an unstripped binary.

it seems to be in makeObject()
(the sequence of asm instructions around 'pushl' matches... only place 
in binary where it does)
[...]
0804f643 <makeObject>:
  804f643:       55                      push   %ebp
  804f644:       89 e5                   mov    %esp,%ebp
  804f646:       57                      push   %edi
  804f647:       56                      push   %esi
  804f648:       53                      push   %ebx
  804f649:       83 ec 10                sub    $0x10,%esp
  804f64c:       8b 75 0c                mov    0xc(%ebp),%esi
_804f64f:_      ff 75 10                pushl  0x10(%ebp)
  804f652:       56                      push   %esi
  804f653:       ff 75 08                pushl  0x8(%ebp)
  804f656:       e8 75 f0 ff ff          call   804e6d0 <findObject>
  804f65b:       83 c4 10                add    $0x10,%esp
  804f65e:       85 c0                   test   %eax,%eax
[...]

I believe there is a faint possiility that the stack can not grow 
because mmap has placed a page there... it seems unlikely though...
I tried to fill the stack right at the start of main... using a memset 
of 1 MiB size on an auto array...
```
void fill_stack(void)
{
   volatile uint8_t bytes[1024*1024];//1MB
   memset(bytes,0,sizeof(bytes));//and hope it is not optimized away
}
```
It is not optimized out. stack is at 1MiB right at the start...

I still get segfaults... but somewhere else...

polipo[3469]: segfault at 78697080 ip 0805c452 sp bfc9b990 error 4 in 
polipo[8048000+2e000]

this time it failed somewhere else:
  805c43d:       68 93 04 00 00          push   $0x493
  805c442:       68 95 db 06 08          push   $0x806db95
  805c447:       68 f0 e1 06 08          push   $0x806e1f0
  805c44c:       eb 23                   jmp    805c471 
<httpServerFinish+0x56>
  805c44e:       48                      dec    %eax
  805c44f:       0f 9e c2                setle  %dl
_805c452:_      83 7f 60 00             cmpl   $0x0,0x60(%edi)
  805c456:       0f 95 c0                setne  %al
  805c459:       38 c2                   cmp    %al,%dl
  805c45b:       75 44                   jne    805c4a1 
<httpServerFinish+0x86>
  805c45d:       68 e8 ef 06 08          push   $0x806efe8
  805c462:       68 94 04 00 00          push   $0x494

in <httpServerFinish>

what's cmpl?
compare or complement?
compare.. 32 bit mem-immediate ifimnotwrong

earlier:
  805c424:       8b 5d 08                mov    0x8(%ebp),%ebx
  805c427:       8b 7b 14                mov    0x14(%ebx),%edi

ebx is some (pointer)parameter
edi a value some offset(0x14) into it

void
httpServerFinish(HTTPConnectionPtr connection, int s, int offset)

probably the connection..
typedef struct _HTTPConnection {
     int flags;   0....
     int fd;      4
     char *buf;   8
     int len;     Ch
     int offset;  10h
     HTTPRequestPtr request;  14h


assert((connection->pipelined > 1) == (request->next != NULL));

_(request->next != NULL)_

so, where is request assigned?

...
What to do?



------------------------------------------------------------------------------
_______________________________________________
Polipo-users mailing list
Polipo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/polipo-users

Reply via email to