[Libwebsockets] something broke since my last git pull (some hours ago)

"Andy Green (林安廸)" andy at warmcat.com
Mon Feb 18 08:12:24 CET 2013

On 18/02/13 14:58, the mail apparently from Edwin van den Oetelaar included:
> Hello Andy,
> I guess it is something on my system that has gone wrong.
> I compiled your test-server on a different machine and it behaves differently.
> Good thing we have git, (and mercurial and svn) to track all the changes.
> I will let you know how I messed up my system.
> My first guess is mixing autoconf with cmake build process.
> On my system the cmake build will not work as documented, it will not
> build inside a 'build' directory just inside the 'root'.

I have not tried the CMake stuff yet.  I have tried to keep it up to 
date with other changes though, but I couldn't see where it lists things 
for /usr/share, how it can make dist / distclean etc.  So although I am 
glad it is there for Windows people I think Unix guys might be using 
autotools for a while.  Now we have the autogen.sh thing that doesn't 
seem to make problems any more.  (However trying to offer an untested 
Windows build before the CMake stuff was unworkable, so it is definitely 
a big advantage.)

Having said that though, I don't know how CMake activities could tread 
on autotools; if you restart from autogen.sh it should force everything 
in good shape AFAIK.

You might want to do a sanity check of building static on the good 
machine, confirm it's still good then copy over the test server to the 
bad machine for a test.  That'll tell you if it's something in the 
environment of that particular machine (assuming it's the same ARCH).

Another idea is tar up the good build dir and try to just link on the 
bad machine, then after make clean etc and see if there's a point it 
breaks down... if it only works with static libs from the other machine 
that's a big clue, if the good static binary fails too it suggests other 
things etc.


> On Mon, Feb 18, 2013 at 3:02 AM, "Andy Green (林安廸)" <andy at warmcat.com> wrote:
>> On 18/02/13 06:51, the mail apparently from Edwin van den Oetelaar included:
>>> Hello Andy,
>>> I am not sure what happens, but found another problem.
>>> If you return -1 from the LWS_CALLBACK_HTTP
>>> something bad happens, not a 404 not found response.
>>> A close is called on an invalid handle.
>>> Look at this trace (the leaf.jpg) was not installed.
>>> poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7,
>>> events=POLLIN}], 3, 50) = 1 ([{fd=6, revents=POLLIN}])
>>> gettimeofday({1361139514, 258651}, NULL) = 0
>>> recv(6, "GET /leaf.jpg HTTP/1.1\r\nHost: lo"..., 4096, 0) = 403
>>> open("./libwebsockets-test-server/leaf.jpg", O_RDONLY) = -1 ENOENT (No
>>> such file or directory)
>>> close(1845496333)                       = -1 EBADF (Bad file descriptor)
>>> shutdown(6, 2 /* send and receive */)   = 0
>>> close(6)                                = 0
>>> gettimeofday({1361139514, 261950}, NULL) = 0
>>> Can you see where this is coming from ?
>>> my guess is about line 200 in /lib/server.c
>>> Good night (23:51 local time)
>>> Edwin van den Oetelaar
>> It should be fixed by this...
>> http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=0caf9c5acb00083ee21a70bd219079289c0ff02f
>> ... there's an explanation in the commit log.
>> However it's a (symptomless?) close of a nonsense file fd in the case you
>> sent a file "by hand" like the leaf.jpg example... I don't think it has any
>> other ramifications AFAIK.
>> If you still have bigger problems you might want to try winding back your
>> git for the library and your app until it works again, and let me know at
>> which commit it starts to give your problem (and perhaps describe the
>> problem a bit more... when the test server "doesn't work" what does it do?).
>> -Andy

More information about the Libwebsockets mailing list