View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002515 | unreal | ircd | public | 2005-05-07 16:27 | 2005-05-16 00:18 |
| Reporter | Stealth | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Summary | 0002515: Interesting crash... | ||||
| Description | I have no idea what caused this... Here is what I have: In a channel: [12:19:28] * Meghan[Out] is now known as Meghan [12:19:28] * Meghan is back. Gone for 1h 24m 59s [12:19:35] * Disconnected (gdb) bt #0 0x4007d05f in ?? () #1 0x4007d5e6 in ?? () #2 0x080610be in parse (cptr=0x819ccb0, buffer=0x819cd94 ":services.x-tab.org SVS2MODE", bufend=0x819cdbe "") at parse.c:437 #3 0x08060634 in dopacket (cptr=0x819ccb0, buffer=0x8115ee0 ":services.x-tab.org SVS2MODE Meghan -r+d 1\r\n4m 59s\001\n", length=1) at packet.c:138 #4 0x080666ad in read_packet (cptr=0x819ccb0, rfd=0x4006a268) at s_bsd.c:1447 #5 0x08066e44 in read_message (delay=1, listp=0x8129ce0) at s_bsd.c:1937 #6 0x0805cd0f in main (argc=2, argv=0x0) at ircd.c:1545 #7 0x42015504 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) I talked to Anope about this, and they said tell Unreal... | ||||
| 3rd party modules | |||||
|
|
You probably got some errors from gdb before typing 'bt' eh? (about missing files). Don't know how much experience with *NIX you have but if you could symlink or copy the .so's to the correct tmp/ ones (mentioned by gdb, tmp/FFDSFD.commands.so etc) and then run gdb then you will get a better backtrace. I've also a script that does this, if you prefer that, I'll get back to you later {I've been thinking about including this in something like './unreal backtrace' -- in fact that's a note on my monitor atm ;p} |
|
|
Ok, something took less time than expected... If I'm not mistaken, this little script should work (from your Unreal3.2 directory): -- (echo quit|gdb src/ircd core 2>&1)|\ grep -i 'no such file'|\ awk -F ':' '{ print $1 }'|sort|uniq|\ awk -F '.' '{ system("ln -s ../src/modules/" $2 ".so " $0) }' -- (adjust the name 'core' if your core file is named differently) And then run gdb as usual again and do a 'bt'. Thanks. |
|
|
gdb src/ircd core.22414 GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... Core was generated by `/home/ircd/Unreal3.2.3/src/ircd'. Program terminated with signal 7, Bus error. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from tmp/41318BEF.commands.so...done. Loaded symbols for tmp/41318BEF.commands.so Reading symbols from tmp/6C8A1C9E.fez-cloak.so...done. Loaded symbols for tmp/6C8A1C9E.fez-cloak.so Reading symbols from tmp/4D9D3334.m_uline.so...done. Loaded symbols for tmp/4D9D3334.m_uline.so Reading symbols from tmp/8824FBCA.m_privdeaf.so...done. Loaded symbols for tmp/8824FBCA.m_privdeaf.so Reading symbols from tmp/896FC0B6.m_clones.so...done. Loaded symbols for tmp/896FC0B6.m_clones.so Reading symbols from tmp/5BD0B4CC.chansno.so...done. Loaded symbols for tmp/5BD0B4CC.chansno.so Reading symbols from tmp/B4A556C1.randquote.so...done. Loaded symbols for tmp/B4A556C1.randquote.so Reading symbols from tmp/15F75F0E.m_umode.so...done. Loaded symbols for tmp/15F75F0E.m_umode.so Reading symbols from tmp/BE36CE76.m_killprotect.so...done. Loaded symbols for tmp/BE36CE76.m_killprotect.so ---Type <return> to continue, or q <return> to quit--- #0 0x4007d05f in do_svsmode (cptr=0x819ccb0, sptr=0x819ccb0, parc=4, parv=0x8115520, show_change=1) at m_svsmode.c:429 429 switch (*m) (gdb) bt #0 0x4007d05f in do_svsmode (cptr=0x819ccb0, sptr=0x819ccb0, parc=4, parv=0x8115520, show_change=1) at m_svsmode.c:429 #1 0x4007d5e6 in m_svs2mode (cptr=0x819ccb0, sptr=0x819ccb0, parc=4, parv=0x8115520) at m_svsmode.c:571 #2 0x080610be in parse (cptr=0x819ccb0, buffer=0x819cd94 ":services.x-tab.org SVS2MODE", bufend=0x819cdbe "") at parse.c:437 #3 0x08060634 in dopacket (cptr=0x819ccb0, buffer=0x8115ee0 ":services.x-tab.org SVS2MODE Meghan -r+d 1\r\n4m 59s\001\n ", length=1) at packet.c:138 #4 0x080666ad in read_packet (cptr=0x819ccb0, rfd=0x4006a268) at s_bsd.c:1447 #5 0x08066e44 in read_message (delay=1, listp=0x8129ce0) at s_bsd.c:1937 #6 0x0805cd0f in main (argc=2, argv=0x0) at ircd.c:1545 #7 0x42015504 in __libc_start_main () from /lib/tls/libc.so.6 |
|
|
I see... odd.. Could you type the following on the gdb prompt: -- p parv[1] p parv[2] p parv[3] p m p what -- What version is this btw? And any 3rd party modules? |
|
|
(gdb) p parv[1] $1 = 0x819cdb1 "Meghan" (gdb) p parv[2] $2 = 0x819cdb8 "-r+d" (gdb) p parv[3] $3 = 0x819cdbd "1" (gdb) p m $4 = 0x819cdb8 "-r+d" (gdb) p what $5 = 1073741824 |
|
|
hm.. I don't see the bug here then. There's no reason why it would crash on a switch(*m) if the 'm' pointer is just fine and *m points to '-'. Even the case of 'case '-':' itself could not cause a problem. > Program terminated with signal 7, Bus error. That's ehm 'interesting'. Where did this run at? Your vmware? I'll take a quick look in assembler to make sure there isn't an issue here. Could you email me the core file, src/ircd and commands.so binary (as .zip, .tar.gz or whatever) to [email protected] ? |
|
|
This is an actual box, not VMware The files will be sent soon. |
|
|
hm, forgot to close this. This seemed some kind of "ghost" issue.. looking at the backtrace and even looking at the assembly code it was "impossible".. Also note that the process is killed by SIGBUS, not SIGSEGV. Also looking at the code (the cmd provided) there's pretty much no way it could crash. If this happens again, especially on another machine, then feel free to re-report of course. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-05-07 16:27 | Stealth | New Issue | |
| 2005-05-07 16:39 | syzop | Note Added: 0009896 | |
| 2005-05-07 16:47 | syzop | Note Added: 0009897 | |
| 2005-05-07 16:53 | Stealth | Note Added: 0009898 | |
| 2005-05-07 17:00 | syzop | Note Added: 0009900 | |
| 2005-05-07 17:06 | Stealth | Note Added: 0009901 | |
| 2005-05-07 17:12 | syzop | Note Added: 0009902 | |
| 2005-05-07 17:14 | Stealth | Note Added: 0009903 | |
| 2005-05-16 00:18 | syzop | Status | new => closed |
| 2005-05-16 00:18 | syzop | Note Added: 0009945 |
