Bug 161528 - Calls to XtVaOpenApplication hang
Calls to XtVaOpenApplication hang
Status: CLOSED DUPLICATE of bug 163017
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-23 19:17 EDT by Scott A. Friedman
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-14 02:13:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 19:49 EDT, Scott A. Friedman
no flags Details

  None (edit)
Description Scott A. Friedman 2005-06-23 19:17:09 EDT
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-23 20:39:50 EDT
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 12:40:34 EDT
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 19:34:44 EDT
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 19:49:59 EDT
Created attachment 115963 [details]
Test case to demonstrate seg fault
Comment 5 Wayne Price 2005-07-15 10:09:49 EDT
This may have the same root cause as bug 163017. The symptoms sounds similar.
Comment 6 Scott A. Friedman 2005-07-19 21:56:48 EDT
Yes it does seem like the same problem.

Kinda quiet here....

Comment 7 Mike A. Harris 2005-09-14 02:13:29 EDT

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