"Andy Green (林安廸)"
andy at warmcat.com
Wed Jan 23 13:01:24 CET 2013
On 23/01/13 19:54, the mail apparently from Jack Mitchell included:
> On 18/01/13 23:54, Andy Green wrote:
>> Hi -
>> Is your code arranged like the test server in terms of using the "call
>> me back when I am writable" api when you have something to send, and
>> writing a single thing in the "I am writable" callback?
>> The mystery here is how you end up trying to do multiple things with a
>> dead socket, the library shouldn't be able to call you back even once
>> under those circumstances. However if your code took the (wrong)
>> approach to store the wsi and randomly try to send on it, that can
>> easily happen.
>> Jack Mitchell <ml at communistcode.co.uk> wrote:
>> On 18/01/13 15:42, Jack Mitchell wrote:
>> On 18/01/13 14:04, "Andy Green (林安廸)" wrote:
>> On 18/01/13 21:20, the mail apparently from Jack Mitchell
>> included: Hi -
>> Today I tried out the latest libwebsockets master in
>> my embedded application and gave it a good thrashing.
>> I managed to reproduce a segfault a few times - I have
>> had this issue before but thought I had fixed it but
>> it has reared it's ugly head again in this new release. I
>> Hm sorry to hear that but I am glad to hear you are
>> beating on the library HEAD.
>> have attached a valgrind trace below in the hope that
>> someone could help me out. I think it is trying to
>> write to a dead socket (null pointer) and bailing out.
>> Should there be some extra error checking somewhere to
>> ensure that a dead socket is never written to?
>> Until this week it would have been too expensive, but with
>> the new lookup array approach it should be possible to
>> cheaply confirm the struct websocket you have hold of
>> still jibes with the pollfd it claims to hold and the fds
>> match. I added an api lws_confirm_legit_wsi()
>> and used it on libwebsocket_write... if you think that's
>> the problem you can sprinkle them around and see if it
>> fires. It looks for any inconsistency between what the
>> struct websocket thinks its position in in the polling
>> table and what the polling table thinks. I wasn't really
>> able to tie up the valgrind log with the idea something
>> blows segfaults. The log shows a memcpy inside deflate is
>> reading 2 bytes it shouldn't? -Andy
>> I'm going to investigate some more and will let you
>> know if I find a solution! <snip>
>> Hi Andy, I turned the DEBUG levels right up (1 | 2 | 4 | 8)
>> and it stopped the segfault. I would assume this means that
>> somewhere there is maybe some error checking code that the
>> debug ifdefs out? Jack.
>> Below is a log of me thrashing it so you can see which parts of
>> the code
>> I am giving a good kicking.
> Hi Andy,
> I cannot produce this any more in the latest head. I will go over my
> websocket implementation again at some point to be sure that it's not
> just chance.
If you see it again run it under gdb like this
gdb --args libwebsocket-test-server
if it blows chunks, you can use
to get a nice backtrace that will nail down where the problem is.
More information about the Libwebsockets