Running Ximian-latest for rh72/i386, latest 2.5 kernels (including
2.5.4-pre2, 2.5.4, 2.5.5-pre1).
Symptom:
- clicking on the panel icon for gnome-terminal shows a flicker
of the terminal window coming up then the window disappears.
No leftover processes.
What works 100%:
- regular xterm in 2.5.x
- gnome-terminal in 2.4.x (x in .17, .18-pre9, .18-rc2)
More info:
- doesn't happen 100% of the time, but close
- trying to start gnome-terminal either vanilla or with the
parameters in the icon from an xterm causes
* gnome-terminal window comes up, but no shell prompt; the
window *does not* disappear and program is in a CPU loop
* program detaches from calling xterm even when '&' is
not used
* calling xterm's tty is left in a funny state (sometimes
stty sane^J is required, sometimes tput reset)
Any ideas would be quite welcome - I can go back and try and narrow
down what kernel breaks gnome-terminal if nothing comes up.
Thanks,
--alessandro
"If your heart is a flame burning brightly
you'll have light and you'll never be cold
And soon you will know that you just grow / You're not growing old"
(Husker Du, "Flexible Flyer")
On Tue, 19 Feb 2002 01:03:13 +0100
Alessandro Suardi <[email protected]> wrote:
> Running Ximian-latest for rh72/i386, latest 2.5 kernels (including
> 2.5.4-pre2, 2.5.4, 2.5.5-pre1).
>
> Symptom:
> - clicking on the panel icon for gnome-terminal shows a flicker
> of the terminal window coming up then the window disappears.
> No leftover processes.
>
> What works 100%:
> - regular xterm in 2.5.x
> - gnome-terminal in 2.4.x (x in .17, .18-pre9, .18-rc2)
I noticed this problem also... it seems the problem lies on
devpts, I enabled it on my 2.5.5pre1 build, mounting
devpts with the options given on the "readme" file
made gnome-terminal start on the second try, almost
everytime
[]s!
--
Gustavo Noronha Silva - kov <http://www.metainfo.org/kov>
*---------* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
| .''`. | Debian GNU/Linux: <http://www.debian.org> |
| : :' : + Debian BR.......: <http://debian-br.cipsga.org.br>+
| `. `'` + Q: "Why did the chicken cross the road?" +
| `- | A: "Upstream's decision." -- hmh |
*---------* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
In mailing-lists.linux-kernel, Gustavo wrote:
> I noticed this problem also... it seems the problem lies on
> devpts, I enabled it on my 2.5.5pre1 build, mounting
> devpts with the options given on the "readme" file
> made gnome-terminal start on the second try, almost
> everytime
I also am seeing this problem--it is definitely pts related. I have
noticed that when the problem occurs, if I execute "gnome-terminal &"
from an existing gnome-terminal, a new window comes up, but input and
output from the new shell are still going to the prior gnome-terminal.
'ps' shows both the new gnome-terminal and old gnome-terminal on the
same pts. But sometimes everything works fine.
Cheers, Wayne
On Mon, 18 Feb 2002 21:39:17 -0300
Gustavo Noronha Silva <[email protected]> wrote:
> On Tue, 19 Feb 2002 01:03:13 +0100
> Alessandro Suardi <[email protected]> wrote:
>
> > Running Ximian-latest for rh72/i386, latest 2.5 kernels (including
> > 2.5.4-pre2, 2.5.4, 2.5.5-pre1).
> >
> > Symptom:
> > - clicking on the panel icon for gnome-terminal shows a flicker
> > of the terminal window coming up then the window disappears.
> > No leftover processes.
> >
> > What works 100%:
> > - regular xterm in 2.5.x
> > - gnome-terminal in 2.4.x (x in .17, .18-pre9, .18-rc2)
> I noticed this problem also... it seems the problem lies on
> devpts, I enabled it on my 2.5.5pre1 build, mounting
> devpts with the options given on the "readme" file
> made gnome-terminal start on the second try, almost
> everytime
Hi,
I have the same problem here... I reported it in another thread (look at "Reiserfs Corruption in 2.5.5-pre1")
Maybe it's something with devpts but I enabled only devfs...
If you start the gnome-terminal from an xterm for example it starts but hangs before or shortly after loading bash
Sometimes gnome-terminal starts without problems but most trys it hangs
If you strace gnome-terminal you can see an endless loop doing some funny things (I have deleted the output but I'll post it later the day, including "ps axlwww" output)
Bye
On Mon, 18 Feb 2002 20:00:51 -0800
Wayne Whitney <[email protected]> wrote:
> In mailing-lists.linux-kernel, Gustavo wrote:
>
> > I noticed this problem also... it seems the problem lies on
> > devpts, I enabled it on my 2.5.5pre1 build, mounting
> > devpts with the options given on the "readme" file
> > made gnome-terminal start on the second try, almost
> > everytime
>
> I also am seeing this problem--it is definitely pts related. I have
> noticed that when the problem occurs, if I execute "gnome-terminal &"
> >from an existing gnome-terminal, a new window comes up, but input and
> output from the new shell are still going to the prior gnome-terminal.
> 'ps' shows both the new gnome-terminal and old gnome-terminal on the
> same pts. But sometimes everything works fine.
>
> Cheers, Wayne
Hi,
here are the outputs... maybe someone can understand it ;)
BTW: aterm, eterm and xterm are running without problems...
Bye
OGAWA Hirofumi wrote:
>
> Alessandro Suardi <[email protected]> writes:
>
>> Running Ximian-latest for rh72/i386, latest 2.5 kernels (including
>> 2.5.4-pre2, 2.5.4, 2.5.5-pre1).
>>
>> Symptom:
>> - clicking on the panel icon for gnome-terminal shows a flicker
>> of the terminal window coming up then the window disappears.
>> No leftover processes.
[snip]
> Probably, this problem had occurred in libzvt which gnome-terminal
> is using.
>
> libzvt was using file descriptor passing via UNIX domain socket for
> pseudo terminal. Then because ->passcred was not initialized in
> sock_alloc(), unexpected credential data was passing to libzvt.
>
> The following patch fixed this problem, but I'm not sure.
> Could you review the patch? (attached file are test program)
>
> --- socket.c.orig Mon Feb 11 18:21:59 2002
> +++ socket.c Tue Feb 19 16:20:18 2002
> @@ -501,6 +501,8 @@ struct socket *sock_alloc(void)
> sock->ops = NULL;
> sock->sk = NULL;
> sock->file = NULL;
> +// init_waitqueue_head(&sock->wait); this is needed?
> + sock->passcred = 0;
>
> sockets_in_use[smp_processor_id()].counter++;
> return sock;
Success on first attempt - thanks. Of course since this wasn't
fully reproducable I'll assume the patch fixes the bug, unless
proven wrong.
Thanks again,
--alessandro
On Tue, Feb 19, 2002 at 08:44:39PM +0900, OGAWA Hirofumi wrote:
> --- socket.c.orig Mon Feb 11 18:21:59 2002
> +++ socket.c Tue Feb 19 16:20:18 2002
> @@ -501,6 +501,8 @@ struct socket *sock_alloc(void)
> sock->ops = NULL;
> sock->sk = NULL;
> sock->file = NULL;
> +// init_waitqueue_head(&sock->wait); this is needed?
> + sock->passcred = 0;
The first line is dead since 2.5.4, but the second is the important
bit here. And as well as fixing the gnome-terminal weirdness, it
also fixes the 'portmapper slows box to a crawl' problem, that
Zwane, myself and rth saw..
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On 19 Feb 02 at 20:44, OGAWA Hirofumi wrote:
>
> libzvt was using file descriptor passing via UNIX domain socket for
> pseudo terminal. Then because ->passcred was not initialized in
> sock_alloc(), unexpected credential data was passing to libzvt.
>
> The following patch fixed this problem, but I'm not sure.
> Could you review the patch? (attached file are test program)
I sent simillar patch to Linus and DaveM on Sunday. Unfortunately it
did not found its way into either of these two trees (and IPX oops fix too).
In addition to yours I moved these 'sock->XXX = NULL' into sock_alloc_inode,
as I see no reason why sock->wait should be initialized in sock_alloc_inode,
but all other members in sock_alloc. It caused confusion to me, and
from your comment it looks like that you missed it too. Besides that
root of sockfs uses sock's inode with sock->ops, sk and file being
0x5a5a5a5a without moving initialization from sock_alloc to sock_alloc_inode.
> --- socket.c.orig Mon Feb 11 18:21:59 2002
> +++ socket.c Tue Feb 19 16:20:18 2002
> @@ -501,6 +501,8 @@ struct socket *sock_alloc(void)
> sock->ops = NULL;
> sock->sk = NULL;
> sock->file = NULL;
> +// init_waitqueue_head(&sock->wait); this is needed?
> + sock->passcred = 0;
>
> sockets_in_use[smp_processor_id()].counter++;
> return sock;
Best regards,
Petr Vandrovec
[email protected]
"Petr Vandrovec" <[email protected]> writes:
> On 19 Feb 02 at 20:44, OGAWA Hirofumi wrote:
> >
> > libzvt was using file descriptor passing via UNIX domain socket for
> > pseudo terminal. Then because ->passcred was not initialized in
> > sock_alloc(), unexpected credential data was passing to libzvt.
> >
> > The following patch fixed this problem, but I'm not sure.
> > Could you review the patch? (attached file are test program)
>
> I sent simillar patch to Linus and DaveM on Sunday. Unfortunately it
> did not found its way into either of these two trees (and IPX oops fix too).
> In addition to yours I moved these 'sock->XXX = NULL' into sock_alloc_inode,
> as I see no reason why sock->wait should be initialized in sock_alloc_inode,
> but all other members in sock_alloc. It caused confusion to me, and
> from your comment it looks like that you missed it too. Besides that
> root of sockfs uses sock's inode with sock->ops, sk and file being
> 0x5a5a5a5a without moving initialization from sock_alloc to sock_alloc_inode.
I wish your patch apply to the tree. Thanks.
--
OGAWA Hirofumi <[email protected]>