[IRCServices] Compiling and Crashing on boot under Solaris 9

[Andrew Church]

     Thanks for the detailed bug report.  Particular issues follow:

>First, I had to add a -libs parameter to configure with "-lsocket -lnsl
>-lresolv" so that it would find hstrerror() and gethostbyname().

     These are now properly checked for.

>It refuses to compile
>dynamic modules, but I didn't care enough to try and correct that.

     It looks like Solaris can't handle undefined symbols in shared
objects.  I don't consider this a particularly important problem, since
static linking works fine.

>I also
>had to tell Make to be sure to use bash as the shell, instead of Solaris'
>braindead /bin/sh by adding a SHELL=/usr/local/bin/bash parameter to the
>make command.

     I assume you got "/bin/sh: test: unknown operator -nt"?  This has been
fixed (configure now checks for /bin/test and uses it instead if /bin/sh is
braindead).

>After that it compiles fine.  It still complains that it cannot find
>strtok, although this isn't fatal.  Solaris does seem to have this
>function, however.  Here is the relevant snippet from the configure.log
>when it attempts to locate strtok:

     In this case this was due to a configure typo, but Solaris (at least
Solaris 9) seems to have the same strtok() bug found in Linux glibc, namely
that the following code snippet will return non-NULL for the second call:

    char buf[] = "\0 b c";
    char *s1 = strtok(buf, " ");  /* returns NULL as expected */
    char *s2 = strtok(NULL, "");  /* returns &buf[1]! */

so configure will still report strtok() as not being found.

>SCENARIO 1.  IRC Services was already started with no database files
>present, so that it created blank files.  Services is gracefully shut down
>with SIGTERM (leaving new db files behind), and then restarted.  It
>segmentation faults and dumps core.
[...]
>#0  0x0003b380 in load_one_serverstats (f=0x25e468) at version4.c:2163
>2163        SAFE(read_int32(&tmp32, f));  /* t_quit */

     It shouldn't be possible to get a segfault here unless your memory is
(physically) faulty.

     Can you send me (privately) both of your database sets, so that I can
check them here?

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/