will the websocket server exit somhow?

[pppaulpeter]

Hi Andy,

i saw a lot of example code using the following code which i also used in my project for the websocket service

	while (n >= 0)
		n = lws_service(context, 0);

sometime i found the service would exit for some reason, could you give any hint about this problem? there is no too many open sockets or memory exhuastion error.thanks a lot! @lws-team

[lws-team]

Turn on the verbose lws logs, it should hopefully give a clue.

[pppaulpeter]

Turn on the verbose lws logs, it should hopefully give a clue.

ok, thanks, i will try to reproduce it.

[pppaulpeter]

Turn on the verbose lws logs, it should hopefully give a clue.

ok, thanks, i will try to reproduce it.

I haven’t been able to reproduce the issue so far, but I’ll updates if it occurs again. by the way, is this crash a known problem? my library version is :W: Libwebsockets version: 4.3.3-unknown

but i can't reproduce the crash problem either.

[lws-team]

This kind of backtrace (it is pointless asking about "a crash" without a backtrace) is caused by leaving a sul scheduled while the object containing it was destroyed. You must take care to call lws_sul_cancel(&sul); before the object containing it is destroyed; if the sul was unscheduled it's a NOP, but if scheduled, it takes care to unschedule it so the linked-list of suls does not still contain the about-to-be dead body of your sul.

All of the internal lws suls should always cancel themselves before destruction but any of yours have to do it explicitly.

[pppaulpeter]

This kind of backtrace (it is pointless asking about "a crash" without a backtrace) is caused by leaving a sul scheduled while the object containing it was destroyed. You must take care to call lws_sul_cancel(&sul); before the object containing it is destroyed; if the sul was unscheduled it's a NOP, but if scheduled, it takes care to unschedule it so the linked-list of suls does not still contain the about-to-be dead body of your sul.

All of the internal lws suls should always cancel themselves before destruction but any of yours have to do it explicitly.

but i never use lws_sorted_usec_list_t inside a per-session struct, i just use this api in my code '''lws_set_timer_usecs(wsi, 10 * LWS_US_PER_MS);''' i don't need call lws_sul_cancel(&sul); in the LWS_CALLBACK_CLOSED, correct?

[lws-team]

No any internal use of sul (the old per-wsi timer is done using a sul underneath for a long time) should be handled internally and safe. What is the version of lws?

[lws-team]

If you want to use the single per-wsi timer (it seems you are on v4.3) then make sure you have this patch from Jun 5 c6924a57d8523b753d5fd30705ec4a5b08a53f66 it will be there if you use v4.3-stable branch, or v4.4 / main.

[pppaulpeter]

No any internal use of sul (the old per-wsi timer is done using a sul underneath for a long time) should be handled internally and safe. What is the version of lws?

Hi Andy, this is the version log '''lwsl_warn("Libwebsockets version: %s\n", lws_get_library_version());''' W: Libwebsockets version: 4.3.3-unknown but it should be 4.3.3 stable., i don't know why it print out unknown. do i need upgrade to v4.4?

[lws-team]

It's better to use later stuff generally, v4.4.1 has the patch in.