[X2go-dev] Segmentation fault with x2goclient

Martin Oehler martin.oehler at gmx.net
Sun Jun 5 17:24:10 CEST 2011

Hello list,

I'm using the x2go squeeze packages on both server and client - everything
is pretty standard. The client is started with

  x2goclient --pgp-card

The first connect to the server always works without any problems (we will
find out that it has nothing to do with "first", but since the client 
segfaults at the second connect it is always the first connect that works).

x2golistsessions displays 

S|30.0511 08:46:40|0aa7e04c159a1a4db1ab1fc4b293fbe1|
IP|30007|30008|05.0611 16:33:28|1000|546726|30009|

After pulling the smart card and inserting the card again, the pinentry 
shows up but the session reconnect does not work. The client segfaults. 

I recompiled the current x2goclient from git with debugging support and 
started the binary with above arguments from gdb, resulting in the 
following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xb7002ef2 in QString::operator=(QString const&) () from 
(gdb) bt
#0  0xb7002ef2 in QString::operator=(QString const&) () from 
#1  0x080a287f in ONMainWindow::getSessionFromString (this=0x81cc910, 
    at onmainwindow_part2.cpp:336
#2  0x080a3574 in ONMainWindow::selectSession (this=0x81cc910, 
  sessions=...) at onmainwindow_part2.cpp:924
#3  0x080b0e3f in ONMainWindow::slotListSessions (this=0x81cc910, 
  result=true, output=..., proc=0x8393750) at onmainwindow_part2.cpp:306
#4  0x0810b36e in ONMainWindow::qt_metacall (this=0x81cc910, 
  _c=QMetaObject::InvokeMetaMethod, _id=39, _a=0xbfffeb80) at 

The output from x2golistsessions that produced this segfault is

S|30.0511 08:46:40|0aa7e04c159a1a4db1ab1fc4b293fbe1|
IP|30007|30008|05.0611 16:39:33|1000|546804|30009|

I can reproduce this behaviour when starting x2golistsessions via
ssh for a short time after a session is suspended. After approximately
30-60 seconds the server returns the working output without 
the "DISPLAY=" line.

Connections to a server running on an older Debian Lenny work without
problems, the result from x2golistsessions is consistent.

The cause of this behaviour is the inconsistent output from 
x2golistsessions but I would consider the client crash as at 
least a bit annoying and would propose to check the string
before assignment.

Can we discuss a bugfix for this?

I really don't know why the DISPLAY-line is returned for a short time
after a session suspend, the 52 can be seen in the normal one-line-output 
from x2golistsessions.

Thanks and kind regards,

More information about the x2go-dev mailing list