WebSocket link list crash on page reload

[WayneKeenan]

Hi,

If I reload a page that has an active web socket connection then there is a crash at:
https://github.com/chmorgan/libesphttpd/blob/master/util/cgiwebsocket.c#L149

Presumably the previous page's web socket is no longer valid and there should have been a LL update or guard here?

[chmorgan]

Hi @WayneKeenan, stack trace? I'm guessing the same regarding the ll update but I'm not sure we know where to perform that yet.

[WayneKeenan]

I didn't think it would help a great deal and there's a load of 'private' stuff, but then that was a bit presumptuous/looks good enough from my POV.

Sorry to be lazy and not give more context, not my usual form.
Thanks for the quick response.

edited:

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x401458fd  PS      : 0x00060f30  A0      : 0x8010c0db  A1      : 0x3ffdb430  
0x401458fd: cgiWebsockBroadcast at ...components/libesphttpd/util/cgiwebsocket.c:149

A2      : 0x3ffb680c  A3      : 0x3f40bdc4  A4      : 0x3ffd75ac  A5      : 0xfefefefe  
A6      : 0x3ffb758c  A7      : 0x00000001  A8      : 0x801458f8  A9      : 0x3ffdb400  
A10     : 0x3809781e  A11     : 0x3ffb758c  A12     : 0x3ffb3c90  A13     : 0x00000016  
A14     : 0x00000000  A15     : 0x40404040  SAR     : 0x00000010  EXCCAUSE: 0x0000001c  
EXCVADDR: 0xfefeff1e  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x401458fd:0x3ffdb430 0x4010c0d8:0x3ffdb470 0x40083c7f:0x3ffdb4a0 0x40106a6d:0x3ffdb4d0 0x401a0ffb:0x3ffdb500 0x40106cc2:0x3ffdbc20 0x4010bf5b:0x3ffdbc60 0x400d4b68:0x3ffdbc90 0x400d26ea:0x3ffdbcd0 0x400923ce:0x3ffdbcf0
0x401458fd: cgiWebsockBroadcast at ...components/libesphttpd/util/cgiwebsocket.c:149
0x4010c0d8: 
0x40083c7f: 
0x40106a6d: 
0x401a0ffb: 
0x40106cc2: 
0x4010bf5b: 
0x400d4b68: app_main at 
0x400d26ea: main_task at ...esp/esp-idf-v3.2/components/esp32/cpu_start.c:494
0x400923ce: vPortTaskWrapper at ...esp-idf-v3.2/components/freertos/port.c:403

[chmorgan]

Hmm. Sure you didn't remove some libesphttpd stuff? Who is calling cgiWebsockBroadcast?

[WayneKeenan]

all the blanked out lines are my code, the prior stack entry is:

0x4010c0d8: webserver_websocket_broadcast at .../my_project/src/components/webserver_helper/webserver_helper.c:135

[WayneKeenan]

It just seems to be a case of calling a websocket update on a stale handle

[chmorgan]

Doesn’t this mean your code is calling that function after the connection was closed? I can’t recall the usage off hand but aren’t you receiving callbacks when connections are terminated that would indicate not to send via that connection? I could be totally off on the usage though. I’m not defending the design or approach either, if we can improve it or clarify we should do so. Chris

…

On Sun, Jun 23, 2019 at 9:43 AM Wayne Keenan ***@***.***> wrote: It just seems to be a case of calling a websocket update on a stale handle — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70?email_source=notifications&email_token=AAJH4AAKNTXZVVRD4V7QCHLP354Z5A5CNFSM4H2YWOPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYK64QA#issuecomment-504753728>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJH4ABEHRZGJJRUDX5V4QLP354Z5ANCNFSM4H2YWOPA> .

[WayneKeenan]

The API to publish a broadcast WS message is a NOP if no client has ever loaded the page.

Please look at your example.

But on reload the exact same call crashes.
There are no lifecycle management API’s, which is great. Just a link list bug...

[chmorgan]

Hi @WayneKeenan. Hmm, yeah its simpler if we don't need any lifecycle management. I can't recall who has worked on the websockets most recently but I'm hoping someone will spot this and know what might be going on. If you have some idea about where the issue is we could look into it in more detail.