Package: schroot
Version: 1.4.0-1
Severity: important
$ schroot
E: Child terminated by signal 'Segmentation fault'
schroot.conf is attached. This is new since 1.4.0. I could revert to
1.2.2, but I've upgraded by config for 1.4.
Thanks,
Andrew.
-- System Information:
Debian Release:
On Fri, Feb 05, 2010 at 08:02:57AM -0500, Andrew Schulman wrote:
$ schroot
E: Child terminated by signal 'Segmentation fault'
schroot.conf is attached. This is new since 1.4.0. I could revert to
1.2.2, but I've upgraded by config for 1.4.
Thanks for the report. I've had another user
For the time being, this appears to be when reading a session file
under /var/lib/schroot/session. Unclear why at this point, but
likely to be not coping with a missing type= parameter. Removing
the session file should fix it--there's no problem with session
files created by the new
On Fri, Feb 05, 2010 at 10:15:59AM -0500, Andrew Schulman wrote:
For the time being, this appears to be when reading a session file
under /var/lib/schroot/session. Unclear why at this point, but
likely to be not coping with a missing type= parameter. Removing
the session file should
Thanks. If you could possibly try to run in gdb, that would be
even better. You'll need to install gdb, schroot-dbg and also
libc6-dbg and libstdc++6-4.4-dbg. You can then (as root) run
'gdb /usr/bin/schroot' and in gdb run 'run schroot-options',
wait until the segfault and then type
On Fri, Feb 05, 2010 at 11:54:51AM -0500, Andrew Schulman wrote:
Thanks. If you could possibly try to run in gdb, that would be
even better. You'll need to install gdb, schroot-dbg and also
libc6-dbg and libstdc++6-4.4-dbg. You can then (as root) run
'gdb /usr/bin/schroot' and in gdb
Thanks for that. It looks like a child process, probably one of the
setup scripts, was what failed with the fault. Could you please try
repeating the gdb backtrace, but add 'catch throw' before you run.
This should catch the exception which is thrown on child failure.
(gdb) catch throw
I'm seeing similar symptoms, but their root cause turned out to be
kernel bug #568416 (with 32-bit binaries generally failing to run on
64-bit kernels); Andrew, could that explain your report too?
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger a...@monk.mit.edu (NOT a
On Fri, Feb 05, 2010 at 05:26:15PM -0500, Andrew Schulman wrote:
Thanks for that. It looks like a child process, probably one of the
setup scripts, was what failed with the fault. Could you please try
repeating the gdb backtrace, but add 'catch throw' before you run.
This should catch
9 matches
Mail list logo
