Crash in XtOpenDisplay

Hi,

I don't understand what's happening, because I didn't modify my source
code, I just rearranged the source tree files, without modifying any
line of code.

This used to work (and it still works if I compile and run the old
source tree, but crashes when compiling the new tree).

I'm initializing my app with:

XtToolkitInitialize();
myapp=XtCreateApplicationContext();
dpy=XtOpenDisplay(myapp,NULL,NULL,"myappclass",NULL,0,&argc,argv);

Ding! core dumped at XtOpenDisplay.

dbx says the stack trace is:

Core from signal SIGSEGV: Segmentation violation
(dbx) where
0 strlen
1 GetDatabase
2 XrmPutLineResource
3 XtScreenDatabase
4 _XtDisplayInitialize
5 XtOpenDisplay
6 myapp_initialize
7 main
8 __start

I also tried Purify, but Purify doesn't say anything interesting until
the crash.

I'm on IRIX 6.5.x. The link line has been modified from the old source
tree, because now my code has been splitted in many (smaller) static
libs (with ".a" extension), but apart from my big list of static libs,
the system libs are the same that I linked in the old code, and they
always worked:

-lifl -lGLw -lSgw -lSgm -lXm -lXt -lX11 -lPW -lGLU -lGL -lfastm -lm

I really don't understand what might be happening. Do you see some
suspicious stuff which might be causing this crash?

thanks

[email]zeecanvas@yahoo.com[/email] writes:
[color=blue]
> Core from signal SIGSEGV: Segmentation violation
> (dbx) where
> 0 strlen
> 1 GetDatabase
> 2 XrmPutLineResource
> 3 XtScreenDatabase
> 4 _XtDisplayInitialize
> 5 XtOpenDisplay
> 6 myapp_initialize
> 7 main
> 8 __start[/color]

Well, that is odd. In the xorg 6.9.0 source tree I have here,
GetDatabase (in xc/lib/X11/Xrm.c) calls strlen only on its second
parameter (str). The value of that parameter comes from the
second parameter (line) of XrmPutLineResource (in the same file).
XtScreenDatabase (in xc/lib/Xt/Initialize.c) calls that only in a
loop that stops when the parameter would become NULL. Thus, it
looks like the str parameter of GetDatabase is probably not NULL
but has rather been corrupted in some way... assuming SGI has
the same code in its libraries.

I suggest you find out the parameter values received by each
function on the call stack, and check whether they make sense.
I don't know how one does that with dbx, though.