[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DDD 3.2.92 (i686-pc-linux-gnu) gets SIGSEGV

From: Juha Jäykkä
Subject: DDD 3.2.92 (i686-pc-linux-gnu) gets SIGSEGV
Date: Tue, 13 Mar 2001 10:07:08 +0200
User-agent: Mutt/1.3.12i

  As the subject states, I manage to get repeated SIGSEGV's from
ddd. The output of --configuration and version information of ddd and
gdb are attached; --trace and --check-configuration end up SIGSEGVing
as well.
  Situation: I have used ssh to forward all X11 traffic from the host
running ddd to my workstation. The workstation only accepts
connections from localhost by currently logged on user; standard X
security. This is standard openssh with -X parameter, nothing
fancy. For some reason, if I leave the ssh connection open for
extended periods of time (day or so), I start getting the message (on
my workstation):
X11 connection rejected because of wrong authentication at Tue Mar 13 09:49:32 
Rejected connection at Tue Mar 13 09:49:32 2001: X11 connection from 
port 34173

  I suspect the MIT magic cookie has expired or something like that
because other than keeping the connection open, I have done nothing. I
do not have the time, nor the knowledge of X internals, to dig into
that. Usually the forwarding, and ddd over it, works fine. I couldn't
make any other program SIGSEGV when it is being rejected
similarly. They simply exit as if they were normally rejected. By
"normally" I mean a situation, where I, for example, manually change
the DISPLAY variable to point directly to my workstation, bypassing
the ssh tunnel, in which case, I simply get:
Xlib: connection to "workstation:0.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: workstation:0.0

  I can not be entirely certain this is indeed ddd's fault since the
connection rejection message actually sees my host IP,
which, to my understanding, it shouldn't since it is ssh
forwarded. Besides my workstation has a routable IP; the other host
has not. There is a firewall in between, doing NAT (which is the real
reason for ssh forwarding anyway). On the other hand, no other program
gets sigsegv's in the same situation.

Attachment: ddd-debian
Description: Text document

Attachment: ddd-log
Description: Text document

Attachment: ddd-ver
Description: Text document

Attachment: gdb-ver
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]