Re: running legacy xview X11 applications via terminal app vs xterm
Re: running legacy xview X11 applications via terminal app vs xterm
- Subject: Re: running legacy xview X11 applications via terminal app vs xterm
- From: Frank Delaglio <email@hidden>
- Date: Mon, 21 Mar 2011 20:05:54 -0400
Greetings, all ...
Many thanks for everyone's input on this issue.
It is indeed unusual. But whatever its cause, this behavior has been
observed by several users, and a couple of responses are below.
While I still like the XView library a lot, in my hands,
applications which use the XView library can be fragile with
respect to things such as locale setting, mouse focus behavior,
and visual class/depth. Also, while it seems trivial, the XView
library always searches for a text editing menu on initialization,
using environment variable EXTRASMENU -- in original versions of
XView, this search was crash-prone, we've tried to improve it a bit.
One other source of troubles, the XView library requires fonts which
are not always available by default, although this problem is
easy to identify when it happens. And as a final comment, the
library is complicated, and it does some unusual things to provide
object-oriented behavior in plain "C" code. So, to me, the library
can be hard to build.
I would have guessed that the problem is caused by environment variable
settings relating to one of the issues above. But as our users have noted,
resetting environment variables does not seem to help.
The last adjustment to our Mac OS X version of XView
was made around July 2010. At that time, the XQuartz folks released
three versions of X11 in about 30 days. Our XView adjustment involved
replacing multiple calls to XAllocID() with a single call to XAllocIDs()
to fix a crash which manifested in xcb_io(). This was not unexpected,
we had to make this same XView fix earlier for linux implementations of X11.
In reviewing the dtrace examples kindly supplied previously by Ben Eisenbraun,
I didn't see any remarkable differences, and the same list of libraries
and files are opened in both cases -- if there were locale-related
differences, I would have expected some difference in the file access.
The crash log includes libXau ... is it possible that there is some
difference in the X11 authorization environments for xterm and
Terminal.app?
Many thanks again to all.
Cheerful Regards,
Frank
Frank Delaglio, Ph.D.
www.nmrscience.com
--------------------------------------------------------------------------
Comment from our user Dr. Michele Gill:
Greetings Frank and NMRPipers,
Frank--I'm happy to help since I have emailed you privately about
this issue and can reliably reproduce the crash you describe below.
(And I have just confirmed that the bug persists with XQuartz 2.6.1
and NMRDraw v. 5.5 Rev 2011.054.20.55. More specifically, NMRDraw
crashes when launched from within XQuartz but not when launched from
the terminal application.)
--------------------------------------------------------------------------
Comment from our user Dr. Iain Day:
Strange. I've just tried this. If I open an xterm from the XQuartz
dock menu, nmrDraw crashes with a bus error, however, if I start an
xterm from a Terminal.app window, it runs okay, the same as it does if
I start it from the Terminal.app.
Hope this helps,
Iain
---------------------------------------------------------------------------
Process: nmrdraw.app [21842]
Path: =20
/nfs/programs/i386-mac/nmrpipe/20110228/nmrbin.mac/nmrdraw.app
Identifier: nmrdraw.app
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: tcsh [21489]
Date/Time: 2011-03-21 14:14:31.281 -0400
OS Version: Mac OS X 10.6.6 (10J567)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x00000000 ecx: 0x00000a00 edx: 0x00000000
edi: 0xbfffe8f4 esi: 0x00000000 ebp: 0x00000000 esp: 0xbfffe350
ss: 0x0000001f efl: 0x00010282 eip: 0x00000000 cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0x00000000
Binary Images:
0x1000 - 0x1f4fe7 +nmrdraw.app ??? (???) =20
/programs/i386-mac/nmrpipe/20110228/nmrbin.mac/nmrdraw.app
0x273000 - 0x367ff7 +libX11.6.dylib 9.0.0 (compatibility 9.0.0) =20
<B66EB198-3F7F-21DD-50FA-401355AC74D5> /usr/X11R6/lib/libX11.6.dylib
0x389000 - 0x38aff7 +libXau.6.dylib 7.0.0 (compatibility 7.0.0) =20
<CF7C13D2-4C5A-37FC-AAF6-7EAB42BCF8AF> /usr/X11/lib/libXau.6.dylib
0x38e000 - 0x390fe7 +libXdmcp.6.dylib 7.0.0 (compatibility =20
7.0.0) <875B1065-7288-E1DB-CA6C-6FDFCB762407> =20
/usr/X11/lib/libXdmcp.6.dylib
0x8fe00000 - 0x8fe4162b dyld 132.1 (???) =20
<A4F6ADCC-6448-37B4-ED6C-ABB2CD06F448> /usr/lib/dyld
0x91c9f000 - 0x91e46ff7 libSystem.B.dylib 125.2.1 (compatibility =20
1.0.0) <62291026-D016-705D-DC1E-FC2B09D47DE5> =20
/usr/lib/libSystem.B.dylib
0x99904000 - 0x99907fe7 libmathCommon.A.dylib 315.0.0 =20
(compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> =20
/usr/lib/system/libmathCommon.A.dylib
0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???) =20
<62291026-D016-705D-DC1E-FC2B09D47DE5> /usr/lib/libSystem.B.dylib
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden