using xrandr segfaults torchat, and it won't launch until the system is rebooted

[GoogleCodeExporter]

What steps will reproduce the problem?
1. launch torchat
2. use xrandr to change screen configuration (dual screen, going back to single 
screen with xrandr -s 0 etc)
3. torchat segfaults
4. torchat won't launch anymore without a reboot. (killing X doesn't help)

What is the expected output? What do you see instead?
torchat shouldn't segfault

those are the last lines of output when messing with xrandr :
Jan 15 02:38:46.452 [notice] Closing stream for '[scrubbed].onion': hidden 
service is unavailable (try again later).

(python2.7:2872): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 
`GtkWidget'

(python2.7:2872): Gtk-CRITICAL **: IA__gtk_widget_get_display: assertion 
`GTK_IS_WIDGET (widget)' failed

(python2.7:2872): Gdk-CRITICAL **: IA__gdk_x11_display_get_xdisplay: assertion 
`GDK_IS_DISPLAY (display)' failed
Erreur de segmentation

(Erreur de segmentation means segfault)
Afterwards, any time you try to launch torchat, you get this :

koolfy@dotk ~/Torchat $ python torchat.py 
(0) [config,418,main] python version 2.7.1 (r271:86832, Dec 22 2010, 17:20:51) 
[GCC 4.4.5]
(0) [config,421,main] running in portable mode, all data is kept inside the bin 
folder.
(0) [config,425,main] script directory is /home/koolfy/Torchat
(0) [config,426,main] data directory is /home/koolfy/Torchat
(0) Traceback (most recent call last):
(0)   File "torchat.py", line 64, in <module>
(0) main()
(0)   File "torchat.py", line 45, in main
(0) listen_socket = tc_client.tryBindPort(interface, port)
(0)   File "/home/koolfy/Torchat/tc_client.py", line 1870, in tryBindPort
(0) tb()
(0)   File "/home/koolfy/Torchat/config.py", line 267, in tb
(0) print "(%i) ----- start traceback -----\n%s   ----- end traceback -----\n" 
% (level, traceback.format_exc())
(0)   File "/home/koolfy/Torchat/config.py", line 397, in write
(0) self.stdout.write(text.encode("ascii", "replace"))
(0) UnicodeDecodeError
(0) :
(0) 'ascii' codec can't decode byte 0xc3 in position 312: ordinal not in 
range(128)
koolfy@dotk ~/Torchat $ 

What version of the product are you using? On what operating system?
version 0.9.9.458

Please provide any additional information below.
I used opensource radeon r600/700 mesa drivers. If you can't reproduce it may 
be driver-related.

Original issue reported on code.google.com by Koo...@gmail.com on 15 Jan 2011 at 1:47

[GoogleCodeExporter]

to fix the reboot problem: it seems that the port is still in use. use netstat 
-ap to identify what is occupying port 11009 and also there might be an 
instance of tor still running (port 11109), then it should start again.

I will look into the initial cause for the crash and try to reproduce it. It 
seems there is more than only one thing going wrong here, the unicode error is 
not directly related but should not happen also.

Original comment by prof7...@gmail.com on 15 Jan 2011 at 2:53

• Changed state: Accepted

[GoogleCodeExporter]

You were right:
netstat -ap

(...)
tcp        0      0 localhost.localdo:11109 localhost.localdo:49972 TIME_WAIT   
-
(...)

and even when the system's tor daemon stopped, there were still two tor 
processes :
ps ax | grep tor

 9442 pts/2    S      0:00 /bin/sh ./tor.sh
 9454 pts/2    S      0:25 tor -f torrc.txt --PidFile tor.pid

So if you encounter this problem, those are the process you might want to kill :
kill -9 <pid>
so here :
kill -9 9442 && kill -9 9454

I can confirm this makes torchat able to launch again.

I'm using the "portable" source zip file, maybe with the resident package the 
system's tor instance is used and in only takes a /etc/init.d/tor restart to 
clear the port and let it launch again, but since I'm using Gentoo and there is 
no package for torchat, I can't really see if this is the case. (Idk if the sh 
./tor.sh is necessary with the ubuntu package for example)

Concerning the segfault :
it also happens when I use the "restart" command of my WM (awesome WM), so I 
think the problem may not be video driver related, but occur whenever the 
windows manager is in any way "disturbed".
As no other application (gtk, wxgtk or anything) crashes when xrandr or WM 
restart are used, I think it's a problem in torchat (one might think it's a 
flaw in awesome)

I'm in no way competent when it comes to GUI code, but you might want to look 
at your basic approach of handling the display. You may be doing an assumption 
that for example the desktop is always present or something, when in fact it 
may "disappear" for a second when it restarts or adapts to a xrandr change, and 
that may crash torchat.

I hope it helps, sorry I don't have the time right now (nor the experience with 
python) to fix it myself and send you a patch.

Original comment by Koo...@gmail.com on 16 Jan 2011 at 3:12

[GoogleCodeExporter]

It will always start its own tor process, this is the only way to temporarily 
install (and remove) a hidden service (and also it isolates it completely from 
the tor configuration of the system tor service), it will start an instance of 
tor via the tor.sh script (this script is in the same folder and behaves and is 
used in the same way as the bundled tor.exe in the windows version). Normally 
it will react to signal 15 (SIGTERM) and terminate tor and itself when TorChat 
exits.

TorChat is simply not supposed to crash ;-)

I will look into this when I have some time, although I have no idea at the 
moment what might cause this, I don't use any wx objects in any unorthodox way, 
at least not intentionally.

Original comment by prof7...@gmail.com on 16 Jan 2011 at 3:33

[GoogleCodeExporter]

I ran some tests, and commenting any call to the taskbar icon (thus letting the 
main window show up only) did not trigger the crash.

Chances are the problem lies in that portion of the GUI code.

I think that narrows down the possible origin of the problem by quite a bit ;)

Original comment by Koo...@gmail.com on 16 Jan 2011 at 4:25

[GoogleCodeExporter]

I cannot reproduce it here. Even killing my wm (kwin) and starting compiz and 
the killing compiz and starting kwin again does not trigger it.

The taskbar icon contains a timer that will make it blink when there are unread 
messages, could you try to just remove the timer and all calls to it and see if 
it still crashes?

Can you try a different (less exotic) wm to see if it happens with all wms and 
not just with awesome?

The last step would be to try one of the simple example applications that come 
with wx that use the taskbar icon or make a minimal example app that reproduces 
the problem.

Original comment by prof7...@gmail.com on 16 Jan 2011 at 1:44