Closed praseodym closed 11 years ago
I'm going to need either a backtrace or reliable steps to reproduce to resolve this issue.
Can you run ZNC attached to a debugger? (lldb/gdb) see http://wiki.znc.in/Debugging
Thanks, I've attached gdb to my running znc instance. It might be a few days until it crashes again, though.
Any updates @praseodym?
Unfortunately I haven't seen a palaver-related crash since I hooked up gdb. I guess that's a good thing though :)
There we go:
#0 0xb7abe215 in SetAway (bAway=<optimized out>, this=<optimized out>)
at /usr/include/znc/Client.h:137
No locals.
#1 CPalaverMod::HandleUserRaw (this=0xb6814990, pClient=0x801abd08, sLine=...) at palaver.cpp:380
sCommand = {<std::basic_string<char, std::char_traits<char>, std::allocator<char> >> = {
static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x801c6734 "BACKGROUND"}}, <No data fields>}
#2 0xb7ab8402 in CPalaverMod::OnUnknownUserRaw (this=0xb6814990, pClient=0x801abd08, sLine=...)
at palaver.cpp:372
No locals.
#3 0x800ab222 in CModules::OnUnknownUserRaw(CClient*, CString&) ()
No symbol table info available.
#4 0x8009736e in CClient::ReadLine(CString const&) ()
No symbol table info available.
#5 0x8003eda2 in Csock::PushBuff(char const*, unsigned int, bool) ()
No symbol table info available.
#6 0x800459c0 in CSocketManager::Loop() ()
No symbol table info available.
#7 0x80042887 in CSocketManager::DynamicSelectLoop(unsigned long, unsigned long, long) ()
No symbol table info available.
#8 0x800606c8 in CZNC::Loop() ()
No symbol table info available.
#9 0x8002fbef in main ()
No symbol table info available.
Thanks for reporting and catching this @praseodym. This is an issue in ZNC, but I will get this patched tonight in the module.
I just hit the same bug on line 382 (ironic after nearly three weeks without crashes). I'll give the patch a try, thanks!
The Palaver extension sometimes segfaults (taking the entire znc process with it); it looks like this occurs shortly after a Palaver client disconnects.
Unfortunately I cannot provide a stack trace, but these lines appeared in my dmesg for two distinct crashes: