Exception in thread Thread=2 on Ubuntu 14.04

[chris-asl]

Exception in thread Thread=2 on Ubuntu 14.04

[karas84]

That seems a python-xlib error, and from my experience once it raises BadWindow it becomes very unstable so I cannot simply catch it and go on.
Is it replicable? Can you tell me some info about your system (X, python, kernel, unity and so on)?

[chris-asl]

Yes, it happens every time I try and run it.
Here you are:
Ubuntu 14.04.2 64bit
Linux desktop 3.13.0-53-generic
X.Org X Server 1.15.1
Python 2.7.6
unity 7.2.5

I don't know what else to report (if you need more info, I'd be more than happy to post back).

I've noticed that I don't have the latest version (installed from the webupd8 ppa), so I've downloaded the master from GH, extracted at my home folder and merged the icons. Then run the local viberwrapper-indicator.py script and got almost the same error:

Using SYSTEM icons
Using NEW detection method
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "./viberwrapper-indicator.py", line 507, in find_viber
    self.viber_window = XTools.Instance().get_window_by_class_name('ViberPC')
  File "./viberwrapper-indicator.py", line 308, in get_window_by_class_name
    if win.get_wm_class() is not None:
  File "/usr/lib/python2.7/dist-packages/Xlib/xobject/drawable.py", line 660, in get_wm_class
    d = self.get_full_property(Xatom.WM_CLASS, Xatom.STRING)
  File "/usr/lib/python2.7/dist-packages/Xlib/xobject/drawable.py", line 452, in get_full_property
    prop = self.get_property(property, type, 0, sizehint)
  File "/usr/lib/python2.7/dist-packages/Xlib/xobject/drawable.py", line 441, in get_property
    long_length = length)
  File "/usr/lib/python2.7/dist-packages/Xlib/protocol/rq.py", line 1478, in __init__
    self.reply()
  File "/usr/lib/python2.7/dist-packages/Xlib/protocol/rq.py", line 1498, in reply
    raise self._error
BadWindow: <class 'Xlib.error.BadWindow'>: code = 3, resource_id = Xlib.xobject.resource.Resource(0x01000084), sequence_number = 7512, major_opcode = 20, minor_opcode = 0

[karas84]

I just commited a small update. Get if from git and tell me what happens. I'm quite positive that it won't work though (you just need to replace the python script).

[chris-asl]

The first time I run it I got this

Using SYSTEM icons
Using NEW detection method
Error getting WM_CLASS of window 0x06800001
Error getting WM_CLASS of window 0x06800030
Error getting WM_CLASS of window 0x068001a8

And the 2nd, this:

Using SYSTEM icons
Using NEW detection method
Error getting WM_CLASS of window 0x06200697

The first two messages are printed right away, but the next are displayed after a while.

[karas84]

I suppose it's not working even after catching those errors. Could you try running xprop to get info about those windows? Just run 'xprop -id ID' (where ID is 0x06800030 for example).

[chris-asl]

Running it for a while gave these IDs:

Using SYSTEM icons
Using NEW detection method
Error getting WM_CLASS of window 0x00e0655c
Error getting WM_CLASS of window 0x05600077
Error getting WM_CLASS of window 0x06600141
Error getting WM_CLASS of window 0x05600078
Error getting WM_CLASS of window 0x00cc38ae

The output of xprop for all of the IDs was the same (only the ID changes)

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  21 (X_ListProperties)
  Resource id in failed request:  0xe0655c
  Serial number of failed request:  12
  Current serial number in output stream:  12

[karas84]

It beats me, really. It does seem to be an xorg related problem rather than a bug. Do you happen to be using some kind of window manager? Anyway since you said that some time ago all was working well I just pushed a new commit where you can explicity specify to use the first detection method I implemented to find viber. Update the python script and launch it with the following parameter:

--use-old-detection-method

It should output "Using OLD detection method". Give it a try and let me know.

[chris-asl]

Is Unity considered to be a window manager (as well as a Desktop Environment)?
Is there any way I could supply more info? Maybe some configs of my window manager (how would I do that?) ?
I have bad news, tried the new version, and all I got was this

Using SYSTEM icons
Using OLD detection method

Tried without the new flag, and got the same Using NEW detection method.
Also, noticed, that each time I am using Ctrl + C, I get an Error getting window's WM_CLASS of window 0x02a014fb.

[karas84]

As you said Unity is the DE, compiz is the default window manager in ubuntu but that doesn't seem to be the problem. Let's try one last thing, launch the script with:

--use-old-detection-method --use-external-detector 

This will force the script to use a shell command to find viber, mind that you'll need to have the following programs installed:

○ xwininfo
○ grep
○ sed

You'll probably be missing only the first one.

[chris-asl]

I actually had xwininfo installed, and run the script, got this output

Using SYSTEM icons  
Using OLD detection method

but viber didn't open.

I even tried uninstalling viber and viberwrapper-indicator and still had no luck.

[karas84]

It sholud have printed "Using EXTERNAL detector" so something went wrong. Let's try another perspective: launch viber (not the script) and wait for the icon to appear on the top left of the screen, then open a terminal and run:

xwininfo -root -children | grep -i viber

This is my output:

     0x4400006 "ViberPC": ("Viber" "ViberPC")  22x22+0+0  +0+0

Run also this second command:

wmctrl -l | grep -i viber

And that's what I get:

0x0440000d  0  N/A Viber +[my phone number]

[chris-asl]

This is the output of the 1st command 0x6a00006 "ViberPC": ("Viber" "ViberPC") 22x22+0+0 +0+0
And also the output of the 2nd command 0x06a0000d 0 N/A Viber +[my phone number]

[karas84]

Well everything seems fine, the only difference so far is that when i run:

./viberwrapper-indicator.py --use-old-detection-method --use-external-detector

i get this:

Using SYSTEM icons
Using OLD detection method
Using EXTERNAL detector

which is not the same as yours. Did you happen to remember installing something particular that could have broken the script? Did you try rebooting your machine? I'm really lost here but I'd like to solve it ...

[chris-asl]

Just reboot my PC, no change in running the script with those two flags.

No, not really. I could provide some configurations or the installations that I did (or generally anything that you might find helpful) cause I also want this to be fixed, as the indicator wrapper is a really useful app.

[karas84]

I recoded the old detection method. Could you update the script and report the output?

[chris-asl]

This is what I get now:

Using SYSTEM icons
Using OLD detection method (EXTERNAL)

Still, viber doesn't open.

[karas84]

So viber is not starting at all? Can you manually start viber after the script has outputted "Using OLD detection method (EXTERNAL)"?

[chris-asl]

Yes, it doesn't start with viberwrapper-indicator.

After the script has outputted that message, Viber can be opened manually, but there's no icon on the topbar and there is the floating icon of viber on its default top-left position.

[karas84]

There is just one more thing I can tink of, that is viber not being launched correctly. Try the last git so we can be sure of this.

[chris-asl]

I am getting the same output using the same flags --use-old-detection-method --use-external-detector.

So I've looked it up a little and it's stuck in ProcessFinder find method and specifically in the ret.wait() call. Isn't this supposed to return as the ps aux call returns (which always returns immediately)?

I've printed the PID of the process as it's stuck at wait() and it's the PID of the ps aux process (and its status is S).

Hope this helped.

[karas84]

Yes it should, and for me it always does. Try replacing the whole body of the find method with a return True and see if it works.

[chris-asl]

Running that prints

Using SYSTEM icons
Using OLD detection method (EXTERNAL)
Viber Already Running!

(with and without the flags - with the appropriate output for the NEW detection method).

Tracked it down to the external_find_viber static method and I see that the subprocess.Popen call for xwininfo doesn't return.

Also, in the class ViberLauncher, at the run method you have sp_viber.wait(), I think that's a typo and you meant to type p_viber. Changed to that and no luck there.

[karas84]

Yes that's a typo, thanks for spotting it ;). Ok, now make the method return False, this way you are forcing to script to think that viber is not running and go on as it should. The strange thing here is that Popen is blocking when usually it shouldn't. I'll try to find more info about that.

[chris-asl]

Ok, it worked now! Viber opened and the icon (new icon) was at the topbar!
Now, to find why did it happen.
As I see Popen is non blocking. That's really weird.

[karas84]

Great! So let's summarize it up. The problem was in the "ps -aux" subprocess that was blocking even if it wasn't supposed to. Shortcutting that solved it. Is it right? (In that case can you try running the script again without arguments to see if the new method is working too now?)

[chris-asl]

Yes, exactly. Everything seems to be normal, except possibly for the Viber icon at window swticher, it is the old one (don't remember if that's how it is supposed to be).

Downloaded the latest version and without arguments it stays stuck as it did before, and now ret.wait() at ProcessFinder.find() doesn't return.

[chris-asl]

karas84, I'm posting again to inform you that after getting an upgrade from the ppa and rebooting Viber started normaly (with the indicator).
After two or three times that I started viberwrapper-indicator, it stopped working again (had Chrome open).
So, I rebooted again, and have opened it now, many times and it worked just fine (both versions, from ppa and from this repository).
Then, I opened Chrome to write this msg, and it stopped working.
Do you think there might be a correlation?

Update
Ok, now I am pretty sure there's a correlation. Closed Chrome and it opens just fine, opened Chrome and it "broke" again.

[karas84]

Tried using chrome but I see no differece. Maybe it is related to the video driver chrome is using (I'm on 'radeon'). However such behaviour is indeed strage. I tried wrapping the process finder class in a thread since I used this "trick" in other projects for a similiar situation but I don't know if it will do anything at all. Try updating and let me know. If even this fails I'll probably be removing the subprocess thing completely since it seems to be unreliable.

[karas84]

@chris-asl Thanks to @krya the problem has been probably found. I committed the new version, let me know so I can close the issue. (Try the new method too by not using any argument)

[chris-asl]

As I see from your commit, you were passing the stdin=subprocess.PIPE as well. So did removing the wait or redirecting the stdin fixed the deadlock?

It works just fine now 👍 Tested while Chrome was open :)

[karas84]

It was the wait() that deadlocked in some cases. I also removed the stdin pipe because I didn't need to redirect it and wanted to simplify stuff a little. Finally we can close this :) Thank you for your time.