[buildd-tools-devel] Bug#512350: [Buildd-tools-devel] Bug#512350: Bug#512350: schroot Segfaults When Run From eesh

[Roger Leigh]

On Wed, Jan 21, 2009 at 12:04:07AM -0500, Jacob Sherwood wrote:
> On Tue, Jan 20, 2009 at 9:57 AM, Roger Leigh <rleigh at codelibre.net> wrote:
> 
> > 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.
> 
> It's possible that it's the latter case (stdin/stdout/stderr aren't
> opened as expected).  eesh is used for manipulating the enlightenment
> GUI.

OK.  I installed e16 and tried to reproduce the problem.
I used a kdm e16 login (i.e. entire session was e16) or as a virtual
X server using Xnest.

In both cases
  % eesh exec "schroot -p echo foo bar"
or
  % eesh exec schroot -p echo foo bar
worked without segfaulting.

When running Xnest, I started e16 from an xterm terminal:
  % Xnest -geometry 800x600 :1

then ran xterm
  % xterm -display :1
and ran e16 in the xterm on the display, or ran e16 directly:
  % DISPLAY=:1 e16

in both cases, eesh output goes to the terminal I ran e16 from.  If
running from a login manager such as kdm, I didn't get any output.

In all cases, things worked without a segfault.  Could you try
the above to see if it works for you?  How are you starting e16?

> > 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.

[…]

Thanks.
Out of interest, how are you redirecting the output in the eesh shell?

> > Next, try to get the environment from /proc/pid/environ for the
> > schroot process.

[…]
That looks OK.

> > Also, the environment in eesh (I guess just type "set") should be
> > the same, so this would also be useful information.
> 
> (Note, to get the following I ran eesh and typed 'exec schroot -pv
> --debug=notice bash -c set' and redirected that to a text file)

[…]

This also looks fine.

> > Next, run schroot but from eesh and in gdb:
> 
> I'm not quite getting what you want; here is what I did (I have to run
> gdb against eesh since eesh executes schroot):

In this case, in eesh you need to run
  % gdb /usr/bin/schroot
  (gdb) run -p echo foo bar
  [… segfault]
  (gdb) backtrace

This should be possible if you run e16 from a shell and then gdb will
run on that terminal.

> Oddly enough, schroot appears not to have segfaulted but bar.txt is empty:
> [Tue 23:53][pts/19 0]$ cat bar.txt

Unless eesh does shell redirection, I think it will just pass the
redirection bits directly to schroot as command-line arguments.

> I could be screwing something up here, I may play around with this
> some more to see if we can get something more informative.

If you've found anything new out in the meantime, I'd love to hear
about it.  If you could give the suggestions above a try, that would
be great.

While I can't reproduce it myself on an amd64 machine, your system
or environment may be different.  If you can still reproduce it, we
need to find out what the difference is if possible.  One possibility
is if eesh doesn't keep stdin/stdout/stderr open at all (not even
redirected to /dev/null).  However, even then it shouldn't cause a
segfault.  I tested it with null stdout and stderr and it works fine
nonetheless.


Regards,
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20090411/bf935498/attachment.pgp>