Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161528 - Calls to XtVaOpenApplication hang
Summary: Calls to XtVaOpenApplication hang
Keywords:
Status: CLOSED DUPLICATE of bug 163017
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2005-09-14 06:13:29 UTC


Attachments (Terms of Use)
Test case to demonstrate seg fault (deleted)
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):
xorg-x11-6.8.2-37

How reproducible:
Always

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

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
compile.

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[] = {
    NULL
};

int main( int argc, char ** argv )
{
    XtAppContext _theApp;
    Widget _baseWidget;
    cerr << "1" << endl;
    _baseWidget = XtVaOpenApplication(&_theApp,"Test",NULL,0,&argc,argv,
						fallbackResources,
						applicationShellWidgetClass,
						NULL);
    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.