Unexplained segmentation fault with Bahamut 1.8.6
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 programmer, though, so I don't even have any idea what to do with the core file. I've not been able to figure out any pattern to this, other than it seems to happen when everything appears to be running just fine. The server 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 the mailing list for archives or anything in case this question has already been asked and/or answered, so I apologize if I'm sending this e-mail to the wrong place or asking a question that's already been asked. Any help would be greatly appreciated! Allie alliekbean@gmail.com
Do you still have the core? If so, could you attach it to this email? -- Juan Baez From: dalnet-src-bounces@lists.dal.net [mailto:dalnet-src-bounces@lists.dal.net] On Behalf Of Allie K Sent: Tuesday, August 11, 2009 12:43 PM To: dalnet-src@dal.net Subject: [DALnet-src] Unexplained segmentation fault with Bahamut 1.8.6 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 programmer, though, so I don't even have any idea what to do with the core file. I've not been able to figure out any pattern to this, other than it seems to happen when everything appears to be running just fine. The server 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 the mailing list for archives or anything in case this question has already been asked and/or answered, so I apologize if I'm sending this e-mail to the wrong place or asking a question that's already been asked. Any help would be greatly appreciated! Allie alliekbean@gmail.com
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
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
We have been having an occasional weird crash under 64 bit. I believe Kobi has been looking into it, but for the time being I'd suggest recompiling a 32 bit binary. For core investigation, please follow these steps and send in the backtrace: # Open the core with GDB $ gdb bin/ircd core.file # at the gdb prompt, issue a backtrace gdb> bt # capture the output and send it to us Thanks, -epi On Tue, Aug 11, 2009 at 1: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 programmer, though, so I don't even have any idea what to do with the core file. I've not been able to figure out any pattern to this, other than it seems to happen when everything appears to be running just fine. The server 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 the mailing list for archives or anything in case this question has already been asked and/or answered, so I apologize if I'm sending this e-mail to the wrong place or asking a question that's already been asked. Any help would be greatly appreciated!
Allie alliekbean@gmail.com
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
Aaron Wiebe wrote:
We have been having an occasional weird crash under 64 bit. I believe Kobi has been looking into it, but for the time being I'd suggest recompiling a 32 bit binary.
For core investigation, please follow these steps and send in the backtrace:
# Open the core with GDB $ gdb bin/ircd core.file # at the gdb prompt, issue a backtrace gdb> bt # capture the output and send it to us
Thanks, -epi
Has the resolving been fixed in 64bit yet? Last time I tried, the resolving didn't work. /Andreas
On Wed, Aug 12, 2009 at 7:55 AM, Aaron Wiebe <epiphani@gmail.com> wrote:
We have been having an occasional weird crash under 64 bit. I believe Kobi has been looking into it, but for the time being I'd suggest recompiling a 32 bit binary.
For core investigation, please follow these steps and send in the backtrace:
# Open the core with GDB $ gdb bin/ircd core.file # at the gdb prompt, issue a backtrace gdb> bt # capture the output and send it to us
Thanks, -epi
Would you happen to have any advice on how to get it to compile as a 32-bit binary? I've never actually had to compile anything like that thus far, so, I'm kind of at a loss for how to do it. I know this really isn't the place for a discussion like that, but if anyone could point me in the right direction that'd be cool. I'm googling anyway, though! :) Allie
Would you happen to have any advice on how to get it to compile as a 32-bit binary? I've never actually had to compile anything like that thus far, so, I'm kind of at a loss for how to do it. I know this really isn't the place for a discussion like that, but if anyone could point me in the right direction that'd be cool. I'm googling anyway, though! :)
An option would be to install a 32-bit compiler, and then tell the configure script to use that compiler. e.g. CC=/usr/bin/i386-redhat-linux-gcc But what could possibly go wrong? Well, you might wind up linking with some 32-bit libraries and some 64-bit libraries, that would be bad... The safest way to compile 32-bit binaries on a 32-bit platform is to use a chroot environment, with only 32-bit compilers and libraries stored inside the chroot. More info: http://multimedia.cx/eggs/about-that-32-bit-chroot/ https://wiki.ubuntu.com/DebootstrapChroot Compile the binary from inside the chroot environment, then when done copy the binary out of it. You'll need 32-bit versions of some system libraries installed system-wide also (with apt-get), in order to be able to run the executable, howeevr. What you don't want to do is have 32-bit binaries and 64-bit binaries linked together, or a binary linked with a mixture of 32-bit and 64-bit libraries, either would be bad. -- -J
participants (5)
-
Aaron Wiebe -
Allie K -
Andreas -
James Hess -
Juan Baez