View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002307 | unreal | ircd | public | 2005-01-29 15:23 | 2005-02-28 10:57 |
| Reporter | sc1 | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | open | ||
| Product Version | 3.2.3 | ||||
| Summary | 0002307: ircd crashes some times. | ||||
| Description | core file details; #0 0x0806a192 in read_message (delay=2, listp=0x8135020) at s_bsd.c:1917 1917 if (FD_ISSET(cptr->fd, &read_set)) | ||||
| 3rd party modules | |||||
|
|
First, please actually read the instructions about posting a bug. You neglected to include a back trace. Second, Red Hat 3? I assume you mean Fedora? Also, some explanation about what you think might be causing this would be helpful. |
|
|
First, it was back trace report. 0 0x0806a192 in read_message (delay=2, listp=0x8135020) at s_bsd.c:1917 1917 if (FD_ISSET(cptr->fd, &read_set)) Second, Red Hat Enterprise Linux ES release 3 (Taroon Update 4) When i looked at the source code, it seems related with dead sockets. But i guess it may releated with the fd limits. Our current user is about ~1400 on a single server, and the most case the crashes occurs at the max level of users conencted. |
|
|
Well if that's a back trace, it seems the stack is corrupted because there should be more frames (read_message is not the entrypoint function). Without being able to see what function called read_message, this will be nearly impossible to fix, especially when you really can't provide any steps to reproduce it. Anyway, perhaps you can gather some information, in gdb do: p cptr p cptr->fd p read_set p &read_set and paste the output. |
|
|
#0 0x0806a192 in read_message (delay=2, listp=0x8135020) at s_bsd.c:1917 1917 if (FD_ISSET(cptr->fd, &read_set)) (gdb) p cptr $1 = (aClient *) 0xd786a10 (gdb) p cptr->fd $2 = -2 (gdb) p read_set $3 = {__fds_bits = {0, 131072, 0, 0, 0, 134217728, 33554432, 0 <repeats 11 times>, 536870912, 2097152, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 67108864, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 16777224, 0, 0, 134217728, 0 <repeats 83 times>}} (gdb) p &read_set $4 = (fd_set *) 0xbfffb7d0 i hope this helps more |
|
|
it happens almost every day. But mostly it occurs when there are about ~1500 clients. I wonder if it related with the fd_limit. Is there a way to find which function call read_message ? I can run ircd with gdb debugger or any way with screen. |
|
|
Could you send me ([email protected]) the core file, src/ircd binary, and src/modules/commands.so ? (or better: mail me the url, but in either case don't post it here unless you mark the bugnote as private) |
|
|
sorry but i could not send the core file, because the file size is about 430MB. Yes it is real! tmp/BA4F8EFB.rtkl.so: No such file or directory. #0 0x0806a192 in read_message (delay=1, listp=0x812bcc0) at s_bsd.c:1917 1917 if (FD_ISSET(cptr->fd, &read_set)) (gdb) bt #0 0x0806a192 in read_message (delay=1, listp=0x812bcc0) at s_bsd.c:1917 #1 0x08060973 in main (argc=2, argv=0x0) at ircd.c:1529 (gdb) but the new core file gives some information about back trace. could you please check it. |
|
|
I see a 3rd party module, so please try running without that before reporting a crash. If you then still crash, you can read on: Unfortunately your backtrace is of no use, since unreal got (re)started after the crash the .so links got broken... You will have to redo the symlinks to have a proper backtrace. Eg: -- cd tmp ln -s ../src/modules/commands.so B8AD0B0B.commands.so [and more] -- for the exact names you should use, see the errors when trying to run gdb. |
|
|
Reading symbols from /home/muhabbet/Unreal3.2/tmp/BA4F8EFB.rtkl.so...done. Loaded symbols for tmp/BA4F8EFB.rtkl.so #0 0x0806a192 in read_message (delay=1, listp=0x812bcc0) at s_bsd.c:1917 1917 if (FD_ISSET(cptr->fd, &read_set)) (gdb) bt #0 0x0806a192 in read_message (delay=1, listp=0x812bcc0) at s_bsd.c:1917 #1 0x08060973 in main (argc=2, argv=0x0) at ircd.c:1529 (gdb) error is same, but you say it is about the 3rd party modules. then ok i try to check modules. |
|
|
the content of the back trace is changes some times but the bugged function is read_message. i wonder there is a bug releated with the disconnected users. #0 0x0806a192 in read_message (delay=2, listp=0x8135020) at s_bsd.c:1909 1909 if (DoList(cptr) && IsSendable(cptr)) (gdb) bt #0 0x0806a192 in read_message (delay=2, listp=0x8135020) at s_bsd.c:1909 #1 0x08060af3 in main (argc=2, argv=0x0) at ircd.c:1593 (gdb) p cptr->name $1 = "nick_null", '\0' <repeats 52 times> |
|
|
Did you get rid of all your 3rd party modules? so remove loadmodule lines or comment them out for all but commands.so and cloak.so. (Also, be sure to RESTART after that, a rehash is not enough) And verify via /module. Also, no code modifications? |
|
|
what about this bug? It's not the best thing crash bugs to be idle. sc1 did u removed all the 3rd party modules as syzop said? Unreal is crashing again? |
|
|
Nope i do not remove 3rd party module. Just looking for the crash reason in detail. I do a nice logging system for the ircd. ircd crashes sometimes again, and the back trace outputs are always same. but also log system tells the crash mostly occurs when there is an ads. i mean when someone send messages to all clients in anyway likes auto-msg, then the ircd may crashes sometimes(not always occurs). i thought that, maybe there is a issue with the spamfilter, maybe clients buffer got in queue and then clients quit or anything happens then crash! cptr->fd always be -2. i am searching for the exact problem. if i got it, and if it is releated with the core source, i will post it here. |
|
|
Actually I'm just gonna close this bug. We do not help with 3rd party mods (crashes), if you made an error in your code we are not going to trace&fix it. If you can reproduce the bug on an unreal without 3rd party mods and without modifications however, let us know. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-01-29 15:23 | sc1 | New Issue | |
| 2005-01-29 15:39 |
|
Note Added: 0008951 | |
| 2005-01-29 15:46 | sc1 | Note Added: 0008952 | |
| 2005-01-29 15:53 |
|
Note Added: 0008953 | |
| 2005-01-29 16:00 | sc1 | Note Added: 0008954 | |
| 2005-02-01 14:31 | sc1 | Note Added: 0008975 | |
| 2005-02-02 20:31 | syzop | Note Added: 0008985 | |
| 2005-02-04 19:32 | sc1 | Note Added: 0009041 | |
| 2005-02-04 19:37 | syzop | Note Added: 0009042 | |
| 2005-02-04 19:44 | sc1 | Note Added: 0009043 | |
| 2005-02-07 19:43 | sc1 | Note Added: 0009048 | |
| 2005-02-07 19:47 | syzop | Note Added: 0009049 | |
| 2005-02-28 07:12 | vonitsanet | Note Added: 0009346 | |
| 2005-02-28 10:54 | sc1 | Note Added: 0009357 | |
| 2005-02-28 10:57 | syzop | Status | new => closed |
| 2005-02-28 10:57 | syzop | Note Added: 0009358 |
