On Tue, Aug 11, 2009 at 10:18 PM, James Hess <mysidia@gmail.com> wrote:

On Tue, Aug 11, 2009 at 12:43 PM, Allie K<alliekbean@gmail.com> wrote:
> This problem is driving me crazy, and I'm not quite sure what's wrong with
> the server. I'm running Bahamut 1.8.6 with ircservices 5.1.19. At random
> times, the ircd seems to just segfault, dumping core. I'm not really a
[..]
> only has a handful of users on it (maybe 5 at the most?) so it isn't under
> heavy load or anything. I'm running the server on 64-bit Ubuntu 9.04 under
> a Xen virtual machine (commercial VPS host). I didn't see a place to check

When you get a corefile, one of the easiest ways to take a look at it
is to have GDB (the GNU debugger) installed

then issue

#gdb -c /path/to/corefile /path/to/program

eg
# gdb -c core.23589 /usr/local/bin/ircd

You will get a (gdb) prompt, now you can ask gdb to give you a backtrace:

(gdb) bt full

If that's too many hundreds of pages long just "backtrace"

Use (gdb) quit
when done to exit gdb.

The output from a full backtrace may help identify the problem.
If you take a look at the output (and in particular the bottom and
top of the stack), or post it...

Note that it works best if you have provided "-ggdb" as a CFLAG,
and you do not compile with any strip options.

The output may also be hard to decipher if you compiled with heavy
optimizations beyond the simple -O option,

e.g. if the GCC options you used to compile the program contained -O2, -O3

Or one of those hundreds of elaborate -f* optimization options such
as "-fomit-frame-pointer -funroll-loops -finline-functions"

Your debugger may not be able to provide all that much information.

So if 'bt' from within gdb doesn't provide much, you may want to
tweak the CFLAGs settings

--
-J

I'd prefer not to provide the core itself because I know it contains some kinda private stuff. Here's the backtrace, though!

#0 check_userbanned (cptr=0x7fc81663fa28, yflags=672, nflags=0) at userban.c:286
        iptmp = "75499876641970."
        bl = (uBanEnt *) 0x33312e3037393134
#1 0x000000000043fe82 in add_connection (lptr=0xaf5ef0, fd=10) at s_bsd.c:1255
        lin = {next = 0x0, value = {cptr = 0x1, chptr = 0x1, aconn = 0x1, banptr = 0x1, wptr = 0x1,
    cp = 0x1 <Address 0x1 out of bounds>}, flags = 0}
        acptr = (aClient *) 0x7fc81663fa28
        addr = {sin_family = 2, sin_port = 59313, sin_addr = {s_addr = 3565568331}, sin_zero = "\000\000\000\000\000\000\000"}
        len = 0
        ban = <value optimized out>
#2 0x0000000000440fa6 in accept_connection (lptr=0xaf5ef0) at s_bsd.c:1535
        addrlen = 16
        host = "75499876641970.65499876641970.134499876641970.212499876641970\000\000\000"
        newfd = 10
        i = 1
        addr = {sin_family = 2, sin_port = 59313, sin_addr = {s_addr = 3565568331}, sin_zero = "\000\000\000\000\000\000\000"}
#3 0x0000000000461cb5 in engine_read_message (delay=<value optimized out>) at socketengine_poll.c:138
        rr = -2006877952
        rw = 0
        pfd = (struct pollfd *) 0x81eee8
        nfds = 0
        i = 1
        fdflags = 1
        fdtype = 10862928
        fdvalue = (void *) 0xaf5ef0
        cptr = (aClient *) 0x0
        poll_fdarray = {{fd = 0, events = 25, revents = 0}, {fd = 3, events = 25, revents = 1}, {fd = 4, events = 25,
    revents = 0}, {fd = 5, events = 25, revents = 0}, {fd = 6, events = 25, revents = 0}, {fd = 8, events = 25, revents = 0}, {
    fd = 14, events = 25, revents = 0}, {fd = 7, events = 25, revents = 0}, {fd = 9, events = 25, revents = 0}, {fd = 10,
    events = 29, revents = 0}, {fd = 10, events = 25, revents = 0}, {fd = 24, events = 29, revents = 0}, {fd = 25, events = 29,
    revents = 25}, {fd = 17, events = 29, revents = 0}, {fd = 0, events = 0, revents = 0} <repeats 1010 times>}
#4 0x000000000041dfb9 in main (argc=<value optimized out>, argv=0x0) at ircd.c:1127
        uid = 0
        euid = 0
        tmp = "/home/bahamut/ircd/.maxclients", '\0' <repeats 570 times>, "\025ِر\027ب\177\000\000\000\000\000\000\000\000\000\000(\005َ\027ب\177\000\000\rF؛\026ب\177\000\000\024\213ر\027ب\177", '\0' <repeats 66 times>, "\001", '\0' <repeats 151 times>, "\025ِر\027ب\177\000\000\000\000\000\000\000\000\000\000بtٍ\027ب\177\000\000eûٍ\026ب\177\000\000\024\213ر\027ب\177", '\0' <repeats 66 times>, "\001", '\0' <repeats 151 times>, "\025ِر\027ب\177\000\000\000\000\000\000\000\000\000\000بtٍ\027ب\177\000\000شث(\027ب\177\000\000\024\213ر\027ب\177", '\0' <repeats 66 times>...
        mcsfp = <value optimized out>
        conferr = <value optimized out>

So does that seem to contain any useful information? I think the configure is pretty much the default compile options aside from a prefix change, so there's probably not an additional level of debugosity added. I can recompile it and try again if nothing in that backtrace is helpful. Thanks very much for your help!

Allie