shellinaboxd core dumps on signal 11 after unknown error

[GoogleCodeExporter]

We're running shellinabox with the following arguments:

/usr/local/bin/shellinaboxd -b -p 4200 --css=white-on-black.css --css=siab.css 
-t --disable-ssl-menu

This is running on FreeBSD 7.1-RELEASE and runs for a fairly long time, then 
seems to randomly core dump.  I am not finding any cores, but are there some 
debug options I can enable to perhaps track this down?  Typically, we'll have 
about 15 different sessions at a give time on each server.

Original issue reported on code.google.com by mnsli...@gmail.com on 13 Oct 2010 at 7:16

[GoogleCodeExporter]

Is this with the top of the tree in Subversion, or are you running the 
pre-packaged version? I recently fixed a bug that was triggered by newer 
versions of gcc and that could result in an occasional segmentation fault.

Other than that, yes, core files would be very useful. ShellInABox deliberately 
disables core files, as there is a small risk that they could included 
security-sensitive data (e.g. user passwords).

You can edit the main() function in shellinabox/shellinaboxd.c. At the very top 
of it, there is a call to prctl() and a little further down a call to 
setrlimit(RLIMIT_CORE). Comment both of these lines out, and you should again 
be able to get core files.

Original comment by zod...@gmail.com on 13 Oct 2010 at 11:55

[GoogleCodeExporter]

We're running from source package 2.10 built from FreeBSD ports.  If you like, 
I can try building from current svn tree, and see if that helps.  I will also 
modify shellinaboxd.c and enable core files.

Original comment by mnsli...@gmail.com on 14 Oct 2010 at 12:55

[GoogleCodeExporter]

I've enabled cores, as you suggested above, and I'll try to pull some debug 
data tomorrow.  I've added a patch for the FreeBSD port and created an option 
to compile with core dump support.  I plan on push this change out to our 
production server tomorrow morning and I'll let you know what I find when I get 
a core dump and I run it through gdb.

I will make certain to use the SVN version of shellinabox so we're not 
analyzing an old bug, unless you'd rather I run it agains 2.10 to make sure 
it's not a different one.

Original comment by mnsli...@gmail.com on 14 Oct 2010 at 5:36

[GoogleCodeExporter]

You should definitely make sure you run the code in SVN. It has had a few 
recent fixes that might be relevant.

Original comment by zod...@gmail.com on 14 Oct 2010 at 6:31

[GoogleCodeExporter]

OK, building that now (was waiting for a reply) and I'll push it out to our 
users first thing in the morning.

Original comment by mnsli...@gmail.com on 14 Oct 2010 at 6:36

[GoogleCodeExporter]

I'm getting segmentation faults too but have no idea how to access core dump 
files... I'm using SVN

Original comment by DLacew...@gmail.com on 19 Nov 2010 at 6:22

[GoogleCodeExporter]

I would definitely like to see debugging output for the crash that you are 
experiencing.

By default, shellinabox disabled core files, as they could conceivably leak 
sensitive data. But you can re-enable them by commenting out the very top of 
main() in shellinabox/shellinaboxd.c. Make sure that neither 
prctl(PR_SET_DUMPABLE) nor setrlimit(RLIMIT_CORE) gets called.

You also need to enable core dumps in your shell prior to launching your copy 
of shellinaboxd. Typically, you would do this by typing "ulimit -c unlimited".

Once you have a coredump, run "gdb shellinaboxd core". On some systems, the 
filename for the core file might include the PID. If so, make sure you pick the 
right filename. If you have multiple core files "ls -l --sort=time core*" is 
usually helpful.

In gdb, type "bt", "disassem", and "info registers". If you can get me the 
output of these commands, that should help a lot. Make sure you keep the core 
file and the shellinaboxd binary around for a few days. If I need additional 
information, I'll ask you for it.

Original comment by zod...@gmail.com on 19 Nov 2010 at 6:29