How do I debug SOGo?

Usage

Development

Administration

Prerequisites

First, make sure you’ve installed the debugging symbols for GNUstep, openchange, samba4, SOGo and SOPE. On RHEL-based distributions, debugging symbols will be located in packages with the “debuginfo” suffix, while on Debian-based distributions, the suffix is “dbg”.

So, on RHEL-based distributions, proceed with the following command:

yum install sogo-debuginfo sope49-debuginfo gnustep-base-debuginfo

On Debian-based distributions, proceed with the following command:

apt-get install libgnustep-base*-dbg sogo-dbg sope4.9-dbg openchangeserver-gdb

On older Debians (Squeeze), the gdb version shipped with the system won’t work with PIE executables. To workaround this problem, a newer gdb must be installed from the backports.

1. Add this line to /etc/apt/sources.list (or add a new file with the “.list” extension to /etc/apt/sources.list.d/):

   deb http://backports.debian.org/debian-backports squeeze-backports main

2. Run apt-get update

   1. Install the package apt-get -t squeeze-backports install "gdb"

Using gdb

If you’re only interested in debugging SOGo, make sure it’s first stopped and no “sogod” process is running.

Then, change to the SOGo user and launch SOGo inside gdb:

% su -s /bin/bash - sogo

% gdb --args /usr/sbin/sogod -WOUseWatchDog NO -WONoDetach YES -WOPort 20000 -WOWorkersCount 1 -WOLogFile - -WOPidFile /tmp/sogo.pid

Launch the application using the “run” command (or “r”). This will start SOGo using a single process inside gdb.

Once SOGo is launched, hit Control-C and set breakpoints, like this:

(gdb) b [NSException raise] 
Breakpoint 1 at 0x7ffff5241d90: file NSException.m, line 955. 
 
(gdb) b abort 
Breakpoint 2 at 0x7ffff5352f50: abort. (2 locations)

Resume’s SOGo state, putting it back into a running one:

(gdb) c 
Continuing.

When the application is about to crash, your breakpoints should be raised:

Breakpoint 1, -[NSException raise] (self=0x55555611fe20, _cmd=0x7ffff56f5f00) at NSException.m:955 
(gdb)

At this point, you can produce a back trace using the “bt” command:

(gdb) bt 
#0  -[NSException raise] (self=0x55555611fe20, _cmd=0x7ffff56f5f00) at NSException.m:955 
#1  0x00007ffff5242231 in +[NSException raise:format:] (self=0x7ffff56f6080, _cmd=<optimized out>, name=0x7ffff56f6220, 
    format=0x7ffff56c57f0) at NSException.m:835 
#2  0x00007ffff51b8e89 in characterAtIndex_c (index=306, self=<optimized out>) at GSString.m:1199 
#3  -[GSMutableString characterAtIndex:] (self=0x555555878630, _cmd=<optimized out>, index=<optimized out>) at GSString.m:3797 
#4  0x00007ffff7b73185 in -[NSString(SOGoURLExtension) _rangeOfURLInRange:] (self=0x555555878630, _cmd=0x7ffff7dc9e00, refRange=...) 
    at NSString+Utilities.m:133 
#5  0x00007ffff7b73732 in -[NSString(SOGoURLExtension) _handleURLs:textToMatch:prefix:inRanges:] (self=0x55555610bbf0, _cmd=0x7ffff7dc9ec0, 
    selfCopy=0x555555878630, match=0x7ffff7dc9240, prefix=0x7ffff7dc9260, ranges=0x555555878b70) at NSString+Utilities.m:202 
#6  0x00007ffff7b73c49 in -[NSString(SOGoURLExtension) stringByDetectingURLs] (self=0x55555610bbf0, _cmd=0x7fffea5b6c80) 
    at NSString+Utilities.m:258 
#7  0x00007fffea3a8537 in -[UIxMailPartTextViewer flatContentAsString] (self=0x555556056070, _cmd=0x5555562d6e00) 
    at UIxMailPartTextViewer.m:48

You can also attach to a running sogod process using gdb. For example, if a sogod process is consuming 100% and its PID is 1234, you can attach to it using “gdb -p 1234”. At this point, you can also produce back traces (“bt” or “bt full”), put the process back in the running state (“c”) or interrupt it (Control-C).

Debugging Samba4 and OpenChange

If you are interested in debugging Samba4/OpenChange, you should install the openchangeserver-dbg package and then make sure no samba processes are running prior launching it from gdb:

% gdb --args /usr/sbin/samba -M single -i -d 10

This will start Samba4 inside gdb using a single samba process. You must make sure that you do NOT use Samba4’s internal LDAP server for authentication in SOGo. If you do this, the authentication code in SOGo will cause a deadlock, because the code path is re-entrant (ie., the running Samba4 process will try to connect to itself using the LDAP-based authentication code triggered by the SOGo code it loads). Debugging Samba4 in multithreaded mode is not an option so if you use Samba4’s internal LDAP server for authentication in SOGo, you should use a temporary SQL-based authentication source for testing purposes.

An alternative method for gathering valuable debugging information for Samba/OpenChange/SOGo is to use the panic action samba parameter in order to automatically get a backtrace if samba crashes.

To do so, fetch the gdb_backtrace script from the samba git repository:

curl 'http://git.samba.org/?p=samba.git;a=blob_plain;f=selftest/gdb_backtrace;hb=HEAD' >/usr/local/bin/gdb_backtrace
chmod +x /usr/local/bin/gdb_backtrace

Then add the following to the [global] section of smb.conf:

panic action = /usr/local/bin/gdb_backtrace %d 

Finally, restart samba and trigger the bug (or wait for it to happen…). A backtrace should be logged in the samba log file.

Next thing is to file a detailed bug on http://sogo.nu/bugs.