Crashing at both ends

Juli Mallett juli at clockworksquid.com
Thu Feb 18 11:26:16 PST 2010


Hi David,

Thanks again for catching this — I've updated the source code in
Subversion to handle those errors.  Once I've tested it a bit more, I
will create a new release.

Thanks,
Juli.

On Tue, Feb 16, 2010 at 22:18, David Keeffe <david.keeffe at gmail.com> wrote:
> Hi Juli
>
> Thanks.
>
> I've recompiled with USE_POLL=select - I'll let the two boxes run and see
> what happens.
>
> Next step is to run up an actual Windows box again.
>
> DK
>
> On 17/02/10 16:28, Juli Mallett wrote:
>>
>> Hi David,
>>
>> When I reorganized how IO works, I didn't handle errors from the
>> underlying poll mechanism properly.  I'll try to fix it soon, but in
>> the meantime you might want to rebuild with USE_POLL=select (since
>> select doesn't poll for exceptional conditions) on the command line.
>>
>> Thanks for the report and the positive feedback!  I'll let you and the
>> list know when I've fixed the problem you found.
>>
>> Juli.
>>
>> On Tue, Feb 16, 2010 at 21:22, David Keeffe<david.keeffe at gmail.com>
>>  wrote:
>>
>>>
>>> Hi Juli
>>>
>>> By and large things work OK. I get nice acceleration and some impressive
>>> caching.
>>> I'm proxying samba on ports 445 and 139.
>>>
>>> Anyway, both systems are Redhat-type Linux with code built from the 0.6.2
>>> sources.
>>> One is Centos 5.3; the other is fedora 8. I didn't tweak anything to set
>>> a
>>> particular poll - just what came out of the box!
>>>
>>> I'm running one end with strace to see what happens if and when the HALT
>>> error occurs.
>>>
>>> Here's some strace output from the Centos box - while it's running OK,
>>> BTW.
>>> I'll send more info if/when it crashes.
>>>
>>> 20614 read(7, "\205\0\0\0", 65536)      = 4
>>> 20614 epoll_wait(5, {}, 128, 0)         = 0
>>> 20614 epoll_wait(5, {}, 128, 0)         = 0
>>> 20614 epoll_ctl(5, EPOLL_CTL_MOD, 3, {EPOLLIN|EPOLLOUT, {u32=3,
>>> u64=192809843650
>>> 72387}}) = 0
>>> 20614 epoll_wait(5, {{EPOLLOUT, {u32=3, u64=19280984365072387}}}, 128, 0)
>>> =
>>> 1
>>> 20614 epoll_ctl(5, EPOLL_CTL_ADD, 7, {EPOLLIN, {u32=7,
>>> u64=13814480231311867911}
>>> }) = 0
>>> 20614 epoll_wait(5, {{EPOLLOUT, {u32=3, u64=19280984365072387}}}, 128, 0)
>>> =
>>> 1
>>> 20614 epoll_ctl(5, EPOLL_CTL_MOD, 3, {EPOLLIN, {u32=3,
>>> u64=107374182403}}) =
>>> 0
>>> 20614 writev(3, [{"\205\0\0\0", 4}], 1) = 4
>>> 20614 epoll_wait(5, {}, 128, 0)         = 0
>>>
>>> Does that help?
>>>
>>> David K
>>>
>>> On 17/02/10 16:12, Juli Mallett wrote:
>>>
>>>>
>>>> Hi David,
>>>>
>>>> What kind of system are you using?  Do you know which poll mechanism
>>>> WANProxy is using?  This should be a pretty straightforward problem,
>>>> but I want to make sure I understand the circumstances.
>>>>
>>>> Thanks,
>>>> Juli.
>>>>
>>>> On Tue, Feb 16, 2010 at 20:56, David Keeffe<david.keeffe at gmail.com>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> Hi All
>>>>>
>>>>> Here's another observation - on one end I get -
>>>>>
>>>>> 1266380820.501030 [/io/system/handle] EMERG: Halting: Unexpected write
>>>>> event:<Error>/0 [Success]
>>>>>
>>>>> after the remote end gets:
>>>>>
>>>>> 1266380480.546826 [/io/system/handle] EMERG: Halting: Unexpected write
>>>>> event:<Error>/0 [Success]
>>>>>
>>>>> This is odd as I'm not sure there was traffic at the time.
>>>>>
>>>>> The two system clocks seem to be within a second of each other.
>>>>>
>>>>> (I amended the source to reveal whether the event was in read_callback
>>>>> or
>>>>> write_callback.)
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> David Keeffe
>>>>> _______________________________________________
>>>>> wanproxy mailing list
>>>>> wanproxy at lists.wanproxy.org
>>>>> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>



More information about the wanproxy mailing list