ml at communistcode.co.uk
Fri Jan 18 16:42:09 CET 2013
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?
>> I'm going to investigate some more and will let you know if I find a
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 Mitchell (jack at embed.me.uk)
Embedded Systems Engineer
More information about the Libwebsockets