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