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
19492|knoppix-52-1306738000_stDLXDE_dp24|52|ahostname| 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 /usr/lib/libQtCore.so.4 (gdb) (gdb) bt #0 0xb7002ef2 in QString::operator=(QString const&) () from /usr/lib/libQtCore.so.4 #1 0x080a287f in ONMainWindow::getSessionFromString (this=0x81cc910, string=...) 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 moc_onmainwindow.cpp:285 [...]
The output from x2golistsessions that produced this segfault is
DISPLAY=52 19492|knoppix-52-1306738000_stDLXDE_dp24|52|ahostname| 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, Martin
Hi Martin,
On So 05 Jun 2011 17:24:10 CEST Martin Oehler wrote:
The output from x2golistsessions that produced this segfault is
DISPLAY=52 19492|knoppix-52-1306738000_stDLXDE_dp24|52|ahostname| 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.
Thanks for reporting this.
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.
I encounter such inconsistencies, as well, when working with X2go
client. I have added a work around to python X2go to catch these
irregularities. This workaround was put together at times that
x2goserver was not yet a Git project (thus, at a time I had no
influence on the server code myself).
Can we discuss a bugfix for this?
Sure!
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.
You do not seem like having an idea, yet? If you can find a hint, let
me know. I may find time to look at code more closely on
Tuesday/Wednesday.
If you use pyhoca-gui and start it from the command line, you can
encounter such issues in irregular intervals, as well. Whenever they
occur, some output is shouted to stderr and you won't miss it...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Mike,
On Sun, Jun 05, 2011 at 06:54:04PM +0200, Mike Gabriel wrote:
On So 05 Jun 2011 17:24:10 CEST Martin Oehler wrote:
I encounter such inconsistencies, as well, when working with X2go client. I have added a work around to python X2go to catch these irregularities. This workaround was put together at times that x2goserver was not yet a Git project (thus, at a time I had no influence on the server code myself).
we use the x2gothinclient setup (booted from a Knoppix) at various installations with GPG cards connected to a LDAP or an ADS with very good results so far. Most patches I needed were of rather cosmetic type (putting the card back after a session suspend, clearing the username inside the card after a session and so on). The x2go system is now upgraded since the display manager mode is available (and one doesn't need an LDAP server for only providing the session type, thanks a lot to Heinz for this).
In short: so far, the bugs are bearable for the benefit. Sometimes a session seems to be crashed and needs a reset but it's happening not very often.
Can we discuss a bugfix for this?
Sure!
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.
You do not seem like having an idea, yet? If you can find a hint, let me know. I may find time to look at code more closely on Tuesday/Wednesday.
I think I have a precise idea, it's the statement
print "DISPLAY=$display\n";
in line 49 of x2goumount-session. After removing the line the session reconnect is stable again (there are only a few results when searching the x2goserver package with a grep for DISPLAY).
We could declare this a fix but since there is a lot of command output parsing I would feel better if someone who is more familiar with the code could affirm that this line isn't needed somewhere else. So far I have no problems with this change.
If you use pyhoca-gui and start it from the command line, you can encounter such issues in irregular intervals, as well. Whenever they occur, some output is shouted to stderr and you won't miss it...
I'm very sorry, I didn't test pyhoca-gui or cli yet.
Kind regards, Martin
Hi Martin,
On So 05 Jun 2011 20:09:33 CEST Martin Oehler wrote:
Hi Mike,
On Sun, Jun 05, 2011 at 06:54:04PM +0200, Mike Gabriel wrote:
On So 05 Jun 2011 17:24:10 CEST Martin Oehler wrote:
I encounter such inconsistencies, as well, when working with X2go client. I have added a work around to python X2go to catch these irregularities. This workaround was put together at times that x2goserver was not yet a Git project (thus, at a time I had no influence on the server code myself).
we use the x2gothinclient setup (booted from a Knoppix) at various installations with GPG cards connected to a LDAP or an ADS with very good results so far. Most patches I needed were of rather cosmetic type (putting the card back after a session suspend, clearing the username inside the card after a session and so on). The x2go system is now upgraded since the display manager mode is available (and one doesn't need an LDAP server for only providing the session type, thanks a lot to Heinz for this).
In short: so far, the bugs are bearable for the benefit. Sometimes a session seems to be crashed and needs a reset but it's happening not very often.
Could you please check-out x2goclient from the X2go Git (if not done
so far) and send your Git patch sets to
patches@x2go.org
It would be fabulous if you could contribute your insights to X2go upstream.
I think I have a precise idea, it's the statement
print "DISPLAY=$display\n";
in line 49 of x2goumount-session. After removing the line the session reconnect is stable again (there are only a few results when searching the x2goserver package with a grep for DISPLAY).
I'll take a look immediately.
Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Martin,
On So 05 Jun 2011 20:09:33 CEST Martin Oehler wrote:
I think I have a precise idea, it's the statement
print "DISPLAY=$display\n";
this indeed was old debug output... fixed! http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=54f9ba4f953caaf0...
Thanks for reporting! Package is currently building for our heuler
(nightly-builds) repository (Debian). Launchpad will pull in the code
within the next 5 hours and place the package in ppa:x2go/ppa
Cheers, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hello Mike,
On Sun, Jun 05, 2011 at 08:54:15PM +0200, Mike Gabriel wrote:
On So 05 Jun 2011 20:09:33 CEST Martin Oehler wrote:
I think I have a precise idea, it's the statement
print "DISPLAY=$display\n";
this indeed was old debug output... fixed! http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=54f9ba4f953caaf0...
Thanks for reporting! Package is currently building for our heuler (nightly-builds) repository (Debian). Launchpad will pull in the code within the next 5 hours and place the package in ppa:x2go/ppa
thanks a lot for the quick commit. I'll CC a patch to patches@x2go.org next time.
Do you think we should open a bug concerning the string assignments that lead to the client crash? Might remember us to fix this.
Kind regards, Martin
Hi Martin,
On So 05 Jun 2011 21:59:43 CEST Martin Oehler wrote:
Do you think we should open a bug concerning the string assignments that lead to the client crash? Might remember us to fix this.
Basically, a good idea. However, the bug tracker on code.x2go.org is
not official. It was a draft, but I personally already use it for
python-x2go development. Better than having no bug tracker, at all...
The X2go project in general will probably choose another product.
Whatever bugtracker solution X2go will vote for finally, putting bugs
in the current tracker is - to my point of view - better than loosing
those reports, at all resp. keeping the reports at a non-public place.
So, my suggestions is: send it as mail to bugs@x2go.org and Cc: it to
the x2go-dev ML.
Thanks, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Martin Oehler -
Mike Gabriel