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 Kalliekbean@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

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

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