Bug #95 - Synergys segfault on Solaris10
Google user: skip.montanaro
I built the new synergy-plus on Solaris10. When running
synergys I got an immediate segfault:
(gdb) bt
#0 0xfea2579c in strlen () from /lib/libc.so.1
#1 0xfea7d986 in _ndoprnt () from /lib/libc.so.1
#2 0xfea807e1 in sprintf () from /lib/libc.so.1
#3 0x080dda4d in CLog::print (this=0x813ec38, file=0x8106b32
"synergys.cpp",
line=1115, fmt=0x0) at CLog.cpp:163
#4 0x080855e0 in loadConfig () at synergys.cpp:1115
#5 0x08088294 in standardStartup (argc=1, argv=0x8046cb4) at
synergys.cpp:725
#6 0x08084dfd in main (argc=1, argv=0x8046cb4) at synergys.cpp:759
(gdb) fr 3
#3 0x080dda4d in CLog::print (this=0x813ec38, file=0x8106b32
"synergys.cpp",
line=1115, fmt=0x0) at CLog.cpp:163
163 sprintf(message, "%%s %%s: %%s\n\t%%s,%%d", tmp,
gpriority[priority], buffer, file, line);
(gdb) p message
$1 = "2009-06-15T14:23:37
\000\000\000\000??\023\b\031\231\020\b?j\004\b=?\r\b8?\023\b", '\0'
"NO??(\003??\\004\b\030???.1\000b.1\000\000\030\004\b?S???\004\b\002???\\\004\b
\003??\000\000\000\000????\030???
\003??\b\000\000\000x\004\b?T??\b\002??\\\004\bPg\004\b\000\000\000\000(g\004\b\030???\020???\030\000\000\000\020\000\000\000\020\000\000\000\020\000\000"...
(gdb) p tmp
$2 = "2009-06-15T14:23:37", '\0'
"?`??\006\000\000\000\000\000\000\000\002\020\000\000\000\000\000\000\004",
'\0'
"????\000\000\000\000\000\000\000\000?j\004\b????????\000\000\000\000?j\004\b????\000???@*??hj\004\b5K??????\000\000\000\000dJ??xj\004\b??????\023\b"
(gdb) p g
$3 = 0x0
(gdb) p buffer
$4 = 0x80469ab ""
(gdb) p file
$5 = 0x8106b32 "synergys.cpp"
(gdb) p line
$6 = 1115
The only configure flag was --prefix.
If you need more input I have the core file.
#1
Google user: edw...@carrel.org
It looks like the g_priority[priority] is not pointing where it ought to. I'd be
interested to see what priority is set to when this crashes.
g_priority is a global array defined at the top of CLog.cpp, and so it is a bit
disconcerting that a value therein would point to NULL.
How big is the core file? And which revision of the code base are you running? Being
able to dig within might be really helpful.
#2
Google user: skip.montanaro
Sorry, missed that variable in the report. priority == -1. Obviously not good.
g_priority looks fine:
(gdb) p g_priority
$2 = {0x8109849 "FATAL", 0x810984f "ERROR", 0x8109855 "WARNING",
0x810985d "NOTE", 0x8109862 "INFO", 0x8109867 "DEBUG", 0x810986d "DEBUG1",
0x8109874 "DEBUG2"}
The core file is 6572329 bytes. I used hg to pull the source. Should be pretty
up-to-date.
#4
Google user: edw...@carrel.org
Huh.
Yeah, that make sense now. That log output is being specified at level CLOGPRINT,
represented by the octal value '\057'. Looking into gpriority is done by using the
difference of that value and '\060'. This is where your -1 comes from.
This log level is used in a number of places within synergyc.cpp, but nowhere else in
the codebase. So, two possible options I will explore in the next day or two:
Just remove the LOG calls from synergyc.cpp, and replace them with straight
printfs to standard output.Rearrange the LOG level hierarchy so that CLOG_PRINT has a valid place in the
priority list, and adjust the -d command-line option to manage that.
Aside: Has anyone looked into the possibility of substituting the logging mechanism
within synergy with something like Log4cpp or Log4cxx? The internal logging mechanism
we have is a bit scary looking.
#5
Google user: diablod3
I think this bug is also happening on PPC Linux, but I can't duplicate it on my AMD64
Linux box.
(gdb) bt
#0 0x0fa52614 in strlen () from /lib/libc.so.6
#1 0x0fa172d8 in vfprintf () from /lib/libc.so.6
#2 0x0fa375a4 in vsprintf () from /lib/libc.so.6
#3 0x0fa1ea24 in sprintf () from /lib/libc.so.6
#4 0x1006db3c in CLog::print (this=0x100bb210,
file=0x1007effc "synergys.cpp", line=1115,
fmt=0x1007fd17 "%%s: no configuration available") at CLog.cpp:163
#5 0x1000770c in loadConfig (argc=
argv=
#6 standardStartup (argc=
at synergys.cpp:725
#7 0x10008350 in run (argc=1, argv=0xbffff614) at synergys.cpp:759
#8 main (argc=1, argv=0xbffff614) at synergys.cpp:1292
#6
Google user: diablod3
I checked out S+ from svn, and the bug doesn't make it segfault, just spew crap and
otherwise work correctly (from what I can tell).
[diablo@tempest ~/code/synergy-plus-read-only/bin]$ ./synergyc
2010-03-28T04:41:47 =k?P}i?N =k?T}i?N =k?X}i?N =k?}i?N =k?}i?N =k?d}i?N
=k?h}i?N =k?l}i?N =k?p}i?N =k?t}i?N =k?x}i?N =k?|}i?N =k?}i?N =k?}i?N
=k?}i?N =k?}i?N =k?}i?N =k?}i?N =k?}i?N =k?}i?N =k??}i?N =k??}i?N =k??}i?N
=k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N
=k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N
=k??}i?N =k??}i?N =k??}i?N =k??}i?N =k??}i?N =k?: synergyc: a server address or
name is required
Try `synergyc --help' for more information.
/home/diablo/code/synergy-plus-read-only/cmd/synergyc/synergyc.cpp,705
#7
Google user: diablod3
Let me retract. Soon as I try to "synergys -h" or "synergyc -h", it segfaults.
Running in gdb, gdb omits most of the bt.
(gdb) bt
#0 0x100c70b4 in CLog::output(int, char) const ()
#1 0x100c6a20 in CLog::print(char const, int, char const*, ...) const ()
#2 0x73742074 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Write comment