Bug 429429 - xdvik gets SIGSEGV on a double fullscreen toggle
xdvik gets SIGSEGV on a double fullscreen toggle
Product: Fedora
Classification: Fedora
Component: xdvik (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jonathan Underwood
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-19 16:05 EST by Michal Jaegermann
Modified: 2008-02-15 21:06 EST (History)
2 users (show)

See Also:
Fixed In Version: 3.0-40.5.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-15 21:06:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xdvik-22.84.13-bad_bar.patch (593 bytes, patch)
2008-01-20 18:51 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2008-01-19 16:05:41 EST
Description of problem:

With xdvi window open on some file hit twice ctrl-L (fullscreen toggle).
This results in the following (from gdb, after installing
xdvik-debuginfo and libXt-debuginfo packages):

Program received signal SIGSEGV, Segmentation fault.
XtWidgetToApplicationContext (w=0x0) at Display.c:709
709             retval = _XtGetPerDisplay(XtDisplayOfObject(w))->appContext;
(gdb) where
#0  XtWidgetToApplicationContext (w=0x0) at Display.c:709
#1  0x00002aaaaacf1b00 in XtCallCallbacks (widget=0x0,
    name=0x692f8f "scrollProc", call_data=0x10) at Callback.c:540
#2  0x0000000000420ed7 in Act_fullscreen (w=<value optimized out>,
    event=<value optimized out>, params=0x0, num_params=<value optimized out>)
    at events.c:2602
#3  0x00002aaaaad262ce in HandleActions (w=<value optimized out>,
    event=0x7fff1daa1bc0, stateTree=0xacd3d0,
    accelWidget=<value optimized out>, procs=0xaf11b8, actions=0x2aaaaaf3e280)
    at TMstate.c:636
#4  0x00002aaaaad266e9 in HandleSimpleState (w=0xacd2c0, tmRecPtr=0xacd308,
    curEventPtr=0x7fff1daa1560) at TMstate.c:875
#5  0x00002aaaaad26def in _XtTranslateEvent (w=0xacd2c0,
    event=<value optimized out>) at TMstate.c:1093
#6  0x00002aaaaacff4ae in XtDispatchEventToWidget (widget=0xacd2c0,
    event=0x7fff1daa1bc0) at Event.c:898
#7  0x00002aaaaacffbb0 in _XtDefaultDispatcher (event=0x7fff1daa1bc0)
    at Event.c:1359
#8  0x00002aaaaacfec5b in XtDispatchEvent (event=0x7fff1daa1bc0)
    at Event.c:1415
#9  0x000000000041e1af in read_events (ret_mask=262142) at events.c:5149
#10 0x0000000000422bc6 in do_pages () at events.c:5391
#11 0x0000000000442cb3 in run_dvi_file (filename=<value optimized out>,
    data=0x695210) at xdvi.c:3048
#12 0x000000000042b484 in main (argc=1, argv=<value optimized out>)
    at main.c:1233
#13 0x00000038f701e2b4 in __libc_start_main () from /lib64/libc.so.6
#14 0x0000000000407b59 in _start ()

With 'w' in frame 0 set to 0x0 this is likely not that surprising
but why we end up with such value evades me in this moment.

If '-fullscreen' flag was used on an initial open a segmentation
fault happens only on the third toggle but it is the same one.

Version-Release number of selected component (if applicable):

How reproducible:
always in described circumstances

Additional info:
I do not know if this really applies only to x86_64.  That is
the only rawhide installation I have.

I tried to see if I can reproduce the same thing with xdvi used
in F7 and F8.  It does not happen but once after ctrl-L, ctrl-L
I was left with "no decorations" xdvi window which was always
on the top and not receiving any keystrokes.  Only getting to
a text console and killing an xdvi process from there allowed
me to remove it.  I could not reproduce that behaviour on
subsequent tries.  Apparently there is some race somewhere.
Comment 1 Jonathan Underwood 2008-01-19 20:41:46 EST
Hmm, I can't reproduce this locally on x86_64 using the exact version you have
(22.84.13-7). Is there anything peculiar about the dvi file you're viewing?
Could you attach it to the report? Does it contain images? I don't doubt that
what you see is a problem, but it's tough to debug it without being able to
reproduce it myself.

It's also possible that the current Obsoletes/Provides confusion between tetex
and texlive packages are causing problems. Can you post the output of 

rpm -qa | grep tetex
rpm -qa | grep texlive
rpm -qa | grep ghost
rpm -qa | grep Xaw3d
Jindrich, Patrice, can you reproduce this crash?
Comment 2 Michal Jaegermann 2008-01-20 01:13:44 EST
> Is there anything peculiar about the dvi file you're viewing?

No, I can do that with any dvi file.  Pick up a dvi file from
/usr/share/doc/texmf/ tree and it will do.

> I can't reproduce this locally on x86_64

Thanks for that info.  This got me thinking.  It turns out that
I cannot reproduce that either if I am using metacity for a window
manager.  But the moment I bumped into that crash I was actually
in sawfish.  With that insight I immediately reproduced the same
segfault on a Fedora 7 installation with xdvi 22.84.9 from

The catch is that I tried such toggle, while in sawfish, with
a number of other programs where this is possible and the only
segfault I got (accidentally for the first time) was with xdvi.
Also where I do this toggle using a button on window decorations,
instead of a ctrl-L key, then I can do this with xdvi as many
times I want, while in sawfish, without any ill effects.  This
is not the same operation as ctrl-L produces a window without
a frame or buttons.  OTOH if I will make first a "full screen"
window with a help of a button then I can now repeat ctrl-L
toggle as many times as I wish.  No idea what happens with
other window managers.

I guess that I have to dig deeper to find out what is really
going on here.

It looks like a really low impact issue.

> It's also possible that the current Obsoletes/Provides confusion
> between tetex and texlive packages are causing problems.

No, this is definitely not that.
Comment 3 Jindrich Novy 2008-01-20 05:22:15 EST
Confirmed that I don't see any segfault with metacity with the latest xdvik on
x86_64 and i386 while switching to fullscreen.
Comment 4 Patrice Dumas 2008-01-20 06:13:06 EST
Cannot reproduce in fluxbox either.
Comment 5 Michal Jaegermann 2008-01-20 18:51:11 EST
Created attachment 292301 [details]

I do not know why only sawfish shows the problem but there is an obvious,
after some debugging :-), "copy-and-waste" error in events.c.  An access
to XtCallCallbacks() on line 2602 is guarded by:
 if (resource.keep_flag && orig_y != 0 && globals.widgets.y_bar != NULL) ...
but that function uses globals.widgets.x_bar while from the context 
it is obvious, if you will closer, that y_bar was really meant. 
This bombs out and is wrong anyway even if a segfault is accidentally
avoided. Patch attached. It solves the originally reported problem too.

After a quick scan through events.c it appears that this is the
only instance where globals.widgets.x_bar and globals.widgets.y_bar
were mixed.  OTOH usually an access to these pointers is guarded
by checks that they are not NULL.  It seems to me that this is not
always the case, especially in a code used when MOTIF is defined,
but I was not very thorough and could have miss something.
Comment 6 Jonathan Underwood 2008-01-20 19:30:17 EST
Ok thanks for the patch, and taking the time to debug it. You're really kicking
this version of xdvik into shape!

I've pushed a build with the patch you attached included:


which is tagged as xdvik-22.84.13-9.fc9. The buildsystem is running dog slow at
the moment, but, modulo me having done something dumb, it should be available
sometime soon. 

If all seems well, I'll push this patch upstream too (unless you wanted to).
Comment 7 Michal Jaegermann 2008-01-20 19:43:39 EST
> If all seems well, I'll push this patch upstream too ...

Yes, please do; whatever you will find suitable to push.
Comment 8 Michal Jaegermann 2008-01-20 19:50:52 EST
BTW - a condition guarding bad access in events.c is
if (resource.keep_flag && orig_y != 0 && globals.widgets.y_bar != NULL)
so if you do not have 'resource.keep_flag' set, or if 'orig_y' happens
to be 0, you will not see that segfault - no matter which window
manager is in use.  I did not check if wm was really a red herring.
Comment 9 Michal Jaegermann 2008-01-21 20:16:47 EST
Closing, as the current rawhide version is fixed, but I mentioned
before that I got the same crash on F7; so I fully expect that the
same typo is in the code used by F7 and F8.
Comment 10 Fedora Update System 2008-01-24 17:01:50 EST
tetex-3.0-40.5.fc7 has been pushed to the Fedora 7 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 tetex'
Comment 11 Fedora Update System 2008-02-15 21:06:45 EST
tetex-3.0-40.5.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.