Bug 161528 - Calls to XtVaOpenApplication hang
Summary: Calls to XtVaOpenApplication hang
Status: CLOSED DUPLICATE of bug 163017
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
(Show other bugs)
Version: 4
Hardware: i386 Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-23 23:17 UTC by Scott A. Friedman
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-14 06:13:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test case to demonstrate seg fault (469 bytes, text/plain)
2005-06-24 23:49 UTC, Scott A. Friedman
no flags Details

Description Scott A. Friedman 2005-06-23 23:17:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
I have several applications that use XtVaOpenApplication and they all hang inside that function as of 6.8.2-37

Earlier (well Fedora 3) versions work fine.

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

How reproducible:

Steps to Reproduce:
1. Call XtVaOpenApplication in an X app

Actual Results:  function never returns

Expected Results:  function should return :-)

Additional info:

Comment 1 Scott A. Friedman 2005-06-24 00:39:50 UTC
Apparently, X is segfaulting in XrmStringToQuark according to gdb

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 31814]
0x001cd731 in XrmStringToQuark () from /usr/X11R6/lib/libX11.so.6
(gdb) backtrace
#0  0x001cd731 in XrmStringToQuark () from /usr/X11R6/lib/libX11.so.6
#1  0x05f741cb in XtSetTypeConverter () from /usr/X11R6/lib/libXt.so.6
#2  0x00582193 in _XmRepTypeInstallConverters () from /usr/X11R6/lib/libXm.so.3
#3  0x004ff30d in _XmRegisterConverters () from /usr/X11R6/lib/libXm.so.3
#4  0x0058e916 in _XmScreenRemoveFromCursorCache ()
   from /usr/X11R6/lib/libXm.so.3
#5  0x05f7a7c5 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#6  0x05f7a7f7 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#7  0x05f7a7f7 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#8  0x05f7ac91 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#9  0x05f7af86 in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6
#10 0x05f7b47b in _XtAppCreateShell () from /usr/X11R6/lib/libXt.so.6
#11 0x05fa7ea3 in XtVaAppCreateShell () from /usr/X11R6/lib/libXt.so.6
#12 0x05fa8352 in _XtVaOpenApplication () from /usr/X11R6/lib/libXt.so.6
#13 0x05fa843b in XtVaOpenApplication () from /usr/X11R6/lib/libXt.so.6
#14 0x0810d6f1 in VkApp (this=0x84ffc58, appClassName=0x8120742 "USim2",
    argc=0xbfc4fe20, argv=0xbfc4fea4, options=0x0, numOptions=0) at VkApp.C:139
#15 0x0806a928 in uSimApp::uSimApp ()
#16 0x0806a014 in main ()

This is weird since the *exact* same program works on latest FC3

Any suggestions?

Comment 2 Mike A. Harris 2005-06-24 16:40:34 UTC
Please provide a 100% reproduceable test case, either an existing OSS
application included in Fedora Core, or a standalone test case exhibiting
the problem.

Thanks in advance.

Setting status to "NEEDINFO"

Comment 3 Scott A. Friedman 2005-06-24 23:34:44 UTC
Ok, here is more info - I think I have narrowed this down enough.

As I mentioned before XtVaOpenApplication is crashing on me.
The exact application works fine under FC3. 

After updating to FC4 it no longer works.

The small app below demonstrates the problem. I can reproduce by changing the
compile line and re-running. BTW, The program crashes when run - not during the

Under an updated (6/24) FC4 system with xorg-x11-6.8.2-37

Result RUNS: g++ test.C -o test -lGL -L/usr/X11R6/lib -lXt
Result RUNS: g++ test.C -o test -lGL -L/usr/X11R6/lib -lXm
Result RUNS: g++ test.C -o test -lGLw -lGL -L/usr/X11R6/lib -lXt
Result DIES: g++ test.C -o test -lGLw -lGL -L/usr/X11R6/lib -lXm

My conclusion is that there is some weird interaction between libGLw and libXm
most likely in their library startup/init code.

As you can see only the first compile/link line is needed for this little app
but my app uses GLw and Xm so that is the one I use for my real app.

On an FC3 system with xorg-x11-6.8.2-1.FC3.13 all four versions work.

Sample Application:

#include <iostream>

using namespace std;

#include <Xm/Xm.h>

static String fallbackResources[] = {

int main( int argc, char ** argv )
    XtAppContext _theApp;
    Widget _baseWidget;
    cerr << "1" << endl;
    _baseWidget = XtVaOpenApplication(&_theApp,"Test",NULL,0,&argc,argv,
    cerr << "2" << endl;

Comment 4 Scott A. Friedman 2005-06-24 23:49:59 UTC
Created attachment 115963 [details]
Test case to demonstrate seg fault

Comment 5 Wayne Price 2005-07-15 14:09:49 UTC
This may have the same root cause as bug 163017. The symptoms sounds similar.

Comment 6 Scott A. Friedman 2005-07-20 01:56:48 UTC
Yes it does seem like the same problem.

Kinda quiet here....

Comment 7 Mike A. Harris 2005-09-14 06:13:29 UTC

*** This bug has been marked as a duplicate of 163017 ***

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