On Mon, Jan 19, 2009 at 05:44:52PM -0500, Jacob Sherwood wrote: > Package: schroot > Version: 1.2.1-1 > Severity: important > > schroot segfaults whenever invoked from eesh: > > [Mon 12:49][pts/5 0]$ eesh exec "schroot -p echo foo bar" > > And in /var/log/syslog I see: > Jan 19 17:39:40 wolf kernel: [195438.971879] schroot[2338]: segfault at > 0 ip 7fd0db117050 sp 7fffe4ab46c8 error 4 in > libc-2.7.so[7fd0db09c000+14a000] > > (eesh is e16's (formerly enlightenment) extended shell, if that helps at > all).
Interesting! I haven't seen a segfault in schroot for several years now! Could you possibly try running schroot in a debugger for me to pinpoint where this occurs? Also, the most likely cause (I think) would be something odd being set in the environment, since that's really the only think the shell can mess up, unless it doesn't open stdin/stdout/stderr as expected. Could you first, try: Running with the additional option '--debug=notice' which will turn on debugging output. This will show approximately where the bug is occuring, as well as listing the environment and the other things schroot is doing when starting up. Next, try to get the environment from /proc/pid/environ for the schroot process. If it segfaults too quickly to do this, you can run in gdb and do "break read" (for example) to stop it ASAP. Also see next paragraph for using gdb. Also, the environment in eesh (I guess just type "set") should be the same, so this would also be useful information. Next, if you have the time, you could try running in a debugger to pointpoint the exact place where it fails. This will require building a version of schroot with debugging symbols: apt-get source schroot cd schroot-xxx DEB_BUILD_OPTIONS=nostrip dpkg-buildpackage -us -uc dpkg -i schroot-xxx.deb (plus the other packages if needed) Also make sure these packages are installed: libc6-dbg libstdc++6-xx-dbg (xx=GCC version) libboostxx-dbg (xx=boost version) Next, run schroot but from eesh and in gdb: gdb /usr/bin/schroot run [args] [program will run and then segfault] backtrace [gdb will print a stack trace which should show the point of failure and the calls which let up to this] If you can find time to do this additional investigation, it will make fixing this much faster, and would be greatly appreciated. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org