(Should this be a separate type then?  ini_list_t or something?)

Fix sizeof(char*) leak when reading a webctrl.ini file.

None of these added FREE_AND_NULL() calls should actually do anything.

Still need to comment the lists and ring buffer.

needing to be able to hijack an SSH session.

Currently implemented with socketpair() which is non-Win32 and using
UNIX-domain sockets only since socketpair() on many platforms doesn't
support PF_INET with socketpair().

Something needs to be done about this.

Also, the two extra threads are annoying.

storms as much as possible.

!!!NOTICE!!!
At least Cryptlib 3.2.3a and 3.2.3 (The latest) crashes Synchronet when you
attempt to connect using OpenSSH (SyncTERM with experiment SSH works though)
DO NOT USE THIS UNLESS YOU WANT YOUR BBS TO CRASH!!!

use inkey()/ungetkey() and don't work with down-arrow (ctrl-J). This should
be okay now that input_thread auto-converts Telnet's CR/LF to CR.

error and is fairly common on Linux.

zmodem_recv_file_data() - the offset value was used in rev 1.34 (back when
this change was made) since zmodem_recv_file_frame() accepted the current
file offset as an argument (but doesn't any longer). Mystery solved.

when passed a NaN value (Mozilla bug 284032) - using JSVAL_IS_NUM().

Fix bug.
This effects all range requests (podcasts etc)

This fixes a bug where query strings used with PathInfoIndex indexes were
ignored.

comments.

message is shown as with str_cmds.bin

Currently, when using str_cmds.js the command ``;spy die'' crashes the BBS.

Note: Dunno what line 1983 is about... Borland warns that the value
is unused, but it looks like it was there for a reason... DM?

the test for NPTL should be in there too and that every app which uses
threads, set*id(), and libsbbs.so should call it.

Does jsexec do this?

If not, should it?

Since the only way to correcty detect NPTL is at *runtime*, add that
detection in to main() and honour it throughout.  sbbscon.h makes the
thread_suid_broken variable/macro available to other files which need it.

prevent threads from exiting while ids are beign changed.

the SIG33.

So, looking into this issue has shown me a number of things...
1) THE CAUSE FOR SIGWAIT FAILURE!!!
   The new Linux pthread model sends a "real-time signal" SIG33 to every
   thread when the saved, real, or effective user or group ID changes which
   then allows every thread to synchronize their IDs.  You cannot prevent
   this signal, and it causes the current syscall to fail.
2) Synchronet calls do_seteuid() quite often during startup and, when thread
   setXid is broken, every time a thread starts up.  As a result, you can
   get a storm of SIG33s.  Further, calling setXid() when not all threads
   have processed their SIG33 results in a deadlock apparently.
3) There is no apparent way of telling if all other threads have processed
   their SIG33s yet.

As a result, I've added a 10ms pause after a setXid() call to give it time
to work.  Since this happens while the mutex is held, it should work, but
10ms may be too large or too small or not effective.

This will add 10ms to EVERY threads startup time which will negatively
effect just about everything.  I'll be looking into the possibility that
setXid() is no longer actually broken on Linux and so we can reduce this
issue to only happening while Synchronet is still starting up, rather than
ongoing for every thread.

Thanks to everyone for their patience on the sigwait() failure issue.
Hopefully we'll be able to actually resolve this relatively soon.

NOTE: There will still be the sigwait failures during startup... the hope
is that we can prevent them from being an ongoing issue.

setre?id() since new systems apparently hang on that call when the IDs
are already what you want.  Further, use a single mutex to protect both
do_setuid() and do_seteuid().

The symptoms:
When you connect to the BBS, the user prompt would repeat quickly three
times then drop carrier on you.  Nothing you entered ever showed up.
--OR--
You seem to connect to the BBS, but you never see any output.

This was only easily reproduced when starting the system as a non-root
user.

This has been confirmed on FC3, FC4, and Debian etch.


The cause:
output_thread or input_thread called thread_up() which called do_seteuid()
which hung in setregid().  Since do_seteuid() is holding a mutex at this
point, when the other *put_thread calls thread_up(), it waits forever for
the mutex.  If output_thread starts first, this results in getchr()
returning ^C every time it's called since input_thread_running is false.


Question for DigitalMan:
Should output_thread/input_thread post a semaphore when they're up to prevent
SMP systems from getting far enough into answer() to call IO stuff before the
corresponding thread is running?  A timed semaphore wait in main.cpp then
could be used (you wouldn't want to block forever in case this happens again).