open https://gitlab.synchro.net/main/sbbs/-/issues/495

<code>
$ gdb /sbbs/exec/sbbs '/tmp/core.sbbs!httpSess.3560723'

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/sbbs/exec/sbbs d'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. [Current thread is 1 (Thread 0x7f7ccadfa700 (LWP 3676796))]


(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x00007f7d8f1fdd15 in __vfprintf_internal (s=s@entry=0x7f7ccadf3e80, format=format@entry=0x7f7d8fb9a5f1 "%ld\t%s\t%s\t%s\t%s\t%u\t%lu",
ap=ap@entry=0x7f7ccadf3ff0, mode_flags=mode_flags@entry=0) at vfprintf-internal.c:1688
#2 0x00007f7d8f210bca in __vasprintf_internal (result_ptr=0x7f7ccadf3fe0, format=0x7f7d8fb9a5f1 "%ld\t%s\t%s\t%s\t%s\t%u\t%lu", args=0x7f7ccadf3ff0,
mode_flags=0) at vasprintf.c:57
#3 0x00007f7d8fb6c993 in strListAppendFormat (list=0x7f7ccadf4110, format=0x7f7d8fb9a5f1 "%ld\t%s\t%s\t%s\t%s\t%u\t%lu") at str_list.c:321
#4 0x00007f7d8f6a66f5 in mqtt_client_on (mqtt=0x7f7d8f43b440 <mqtt>, on=0, sock=141, client=0x0, update=0) at mqtt.c:628
#5 0x00007f7d8f40a356 in client_off (sock=141) at websrvr.c:772
#6 0x00007f7d8f4203be in http_session_thread (arg=0x0) at websrvr.c:6776
#7 0x00007f7d8f37f609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8 0x00007f7d8f2a4133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)
</code>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/495#note_3082

Interesting.. this looks like the same crash that took down vert.synchro.net (on Windows) a couple of weeks ago. Good to know it's not a Windows-only issue!

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/495#note_3083

Of course, I just realized I recompiled sbbs on 17th Jan and the crash was on 16th so the core and binary files are not going to line up I expect so not sure if that dump is completely useful or not.

I have another core from Jan 13th and then one from core.sbbs!termNode.3347010 on 15th. Let me know if you want a bt from those as new issues or I can add them here.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/495#note_3085

BT's from those other core dumps could be still useful.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/issues/495#note_3132

This crash is still occurring with the latest changes and I think I know why: the client_list maintained in the mqtt object has pointers to the username for each connected client and in the web server, that points to char buffer in an ephemeral http_session_t instance which is likely being freed already at this point in the code in same race-conditions. Changing the client_t definition to use a char array for the username rather than a pointer should fix this.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

close https://gitlab.synchro.net/main/sbbs/-/issues/495

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net