Bug 442445

Summary: comand line option '-sourceposition' does not work correctly
Product: [Fedora] Fedora Reporter: Jiri Cerny <ji.cerny>
Component: xdvikAssignee: Jonathan Underwood <jonathan.underwood>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: jnovy, pertusus
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 22.84.13-19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-21 16:50:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of two xdvi -unique -debug client,src commands
none
output of working xdvi -unique -debug client,src commands
none
output of xwininfo for the first xdvi window
none
patch correcting the problem none

Description Jiri Cerny 2008-04-14 20:19:22 UTC 
Description of problem:
As described in the manual of xdvi:
"-sourceposition: ....
In addition, when run with this argument (and the -nofork option is not given,
which see), xdvi will always return immediately: if it finds another instance of
xdvi already showing dvi_file, then it will cause that instance to raise its
window and move to the given place in the dvi file; otherwise it will start up
its own instance in the background......" 

This worked in F8, but now, everytime a new window is opened, which is very
annoying. The option '-unique' has the same problem.

Version-Release number of selected component (if applicable):
rpm -q xdvik
xdvik-22.84.13-17.fc9.x86_64

How reproducible: always


Steps to Reproduce:
1.xdvi -unique somedvifile.dvi
2.xdvi -unique somedvifile.dvi
3.two windows are opened instead of one.
Comment 1 Patrice Dumas 2008-04-14 20:24:55 UTC 
I cannot reproduce it on my x386 box, with -unique it reloads in the same window.
Comment 2 Jiri Cerny 2008-04-15 07:17:22 UTC 
Created attachment 302412 [details]
output of two xdvi -unique -debug client,src commands
Comment 3 Jiri Cerny 2008-04-15 07:18:37 UTC 
I can reproduce it always. I attached to the bug output of two successive xdvi
commands with some debugging enabled. Maybe it helps.
Comment 4 Patrice Dumas 2008-04-15 08:15:56 UTC 
I tried the same, and upon inspection of the logs, it seems that the issue is in
x_util.c:1142: CLIENT: Checking window ffffffffffffffe9
x_util.c:1152: CLIENT: Window ffffffffffffffe9: doesn't exist any more, deleting
x_util.c:284: CLIENT: No "xdvi windows" property found
(during the first run).

I attach my logs for a case that works.
Comment 5 Patrice Dumas 2008-04-15 08:17:49 UTC 
Created attachment 302419 [details]
output of working xdvi -unique -debug client,src commands
Comment 6 Patrice Dumas 2008-04-15 08:29:02 UTC 
Maybe you could launch xwininfo and click on the first xdvi window, look at the
window id and report back the comparison with x_util.c:1142: CLIENT: Checking
window ffffffffffffffe9.
Comment 7 Jiri Cerny 2008-04-15 08:46:53 UTC 
Created attachment 302424 [details]
output of xwininfo for the first xdvi window

As you see, the window id looks quite normal. It is not ffffffffffffe9
Comment 8 Jonathan Underwood 2008-04-15 22:35:49 UTC 
Um. Struggling to reproduce this locally. I am wondering if this could be a
window manager bug - Jiri, what WM are you using?
Comment 9 Jiri Cerny 2008-04-16 07:31:14 UTC 
metacity-2.22.0-2.fc9.x86_64. I do not believe it is metacity, since xwininfo
works, but I am really no expert. 

To be sure that it is not related my personal configuration, I have created a
new user on current rawhide. The problem is completely reproducible also by this
new user (with standard gnome desktop)
Comment 10 Jiri Cerny 2008-04-16 12:40:39 UTC 
I was trying to play with the code. What I do not understand is  the following.
If I add on the begining of the function get_window_id in x_utils.c the
following line 

fprintf(stderr, "DEBUGING: %02x %02x %02x %02x\n",
		    window_p[0],window_p[1],window_p[2],window_p[3]);

I get DEBUGING: ffffffe8 01 00 04
I am not a professional programmer, but why printing char produces something
like ffffffe8.
Comment 11 Jiri Cerny 2008-04-17 07:46:26 UTC 
Created attachment 302722 [details]
patch correcting the problem

This (very unprofessional) patch makes my problem disappear. The window id is
non longer fffffffffe9 and, what is more important, -unique switch works.
Comment 12 Jonathan Underwood 2008-04-17 23:07:00 UTC 
Hm, ok, thanks for digging a little deeper with this - I'll have a careful look
over the weekend.
Comment 13 Jonathan Underwood 2008-04-27 23:24:15 UTC 
Have done a build with Jiri's patch applied:

http://koji.fedoraproject.org/koji/taskinfo?taskID=585170

Please test that (assuming it completes successfully). I'll push an update for
F-9 if this fix is good.
Comment 14 Jiri Cerny 2008-04-28 06:56:51 UTC 
The above build works for me. Thanks a lot.
Comment 15 Fedora Update System 2008-04-30 10:09:39 UTC 
xdvik-22.84.13-19.fc9 has been submitted as an update for Fedora 9
Comment 16 Fedora Update System 2008-05-13 15:31:34 UTC 
xdvik-22.84.13-19.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xdvik'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3710
Comment 17 Bug Zapper 2008-05-14 09:26:32 UTC 
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Fedora Update System 2008-05-21 11:07:34 UTC 
xdvik-22.84.13-19.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.