Crash in XtOpenDisplay

[zeec...@yahoo.com]

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

[Kalle Olavi Niemitalo]

zeec...@yahoo.com writes:

> 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

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.

[davea]

Kalle Olavi Niemitalo wrote:
> zeec...@yahoo.com writes:
>
> > Core from signal SIGSEGV: Segmentation violation
> > (dbx) where
> > 0 strlen
> > 1 GetDatabase

...

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

The
where
command in dbx will do that if and only if the functions were compiled
-g
(which the shipped IRIX libraries are not).

dbx also (not shown in the stack trace in the posting) shows the
registers (a0,a2,a2, a3, ...) where $a2 is the second argument (the
integer register) and that is often (not guaranteed) to be the passed
in argument. Especially if it's at 0 or 1 in the stack trace.

The stack trace shown is obviouslyi editted , not showing full dbx
output.

David Anderson

[Kalle Olavi Niemitalo]

"davea" <da...@sgi.com> writes:

> The
> where
> command in dbx will do that if and only if the functions were compiled
> -g
> (which the shipped IRIX libraries are not).
>
> dbx also (not shown in the stack trace in the posting) shows the
> registers (a0,a2,a2, a3, ...) where $a2 is the second argument (the
> integer register) and that is often (not guaranteed) to be the passed
> in argument. Especially if it's at 0 or 1 in the stack trace.

I suppose the OP could set breakpoints at the functions in
question, and then read the arguments from the registers.