I'm currently porting some older software (probably 5/6 years old now)
to a newer OS, with the host of new compilers, libraries, drivers,
etc.. For the most part the port as gone as expected, but there is
one problem that has me utterly stumped and I was hoping the members
of this group could help me brainstorm some ideas.
In certain sections of the software a topLevelShell is created that
contains a glwMDrawingAreaWidgetClass. When this topLevelShell is
destroyed via an XtDestroyWidget() call, the memory is completely
trashed, leading to a variety of seg faults. The most common being:
abbreviated stack trace:
malloc_consolidate() from /lib/tls/libc.so.6
_int_malloc() from /lib/tls/libc.so.6
malloc() from /bli/tls/libc.so.6
XtMalloc() from /usr/X11R6/lib/libXt.so.6
....
The stack trace doesn't tell us much except that the memory is
trashed, and pretty much any X-related action following the
XtDestroyWidget() will cause some variety of this to occur.
Now, here is where it gets interesting. If I change the
glwMDrawingAreaWidgetClass to glwDrawingAreaWidgetClass everything
works fine. Memory is secure and things are good. In researching the
problem on the net I ran across this posting which seemed to be the
same situation as me:
http://bugs.motifzone.net/long_list.cgi?buglist=1241
The bug was created because the GLw libraries were created with a
different sized XmPrimitive class than was included with the X11
distribution leading to library files (libXm and libGLw* for example)
using different sized structures. I guess back in 2004 sometime they
added a tooltips to the Primitive class, yet the mesa libraries at the
time included their own copy of the Xm*.h files leading to the
confusion.
I don't believe this is the exact cause of my problem only because the
libraries I am using are relatively new and should have all been built
with the same versions of X11 via rpm files. I've stripped down my
code to the absolute bare minimum to ensure that it is not something
else in the code that is affecting it, but it always comes back to
glwMDrawingAreaWidgetClass will cause the segFaults and
glwDrawingAreaWidgetClass will not.
Here is a breakdown of my system:
CentOS 4.5 kernel 2.6.9-55
xorg-x11-Mesa-libGL-6.8.2-1.EL.18
xorg-x11-devel-6.8.2-1.EL.18
openmotif-devel-2.2.3-10.1.el4
nvidia drivers version 1.0.8776
I've done an rpm -qR on the openmotif-devel rpm and it says the reqs
are just for xorg-x11-devel, but no version number is given. So I'm
unsure whether these are completely compatible. How do I find that
out?
I've also updated the nvidia drivers to their most recent version, but
it has not made any difference. (I've since reverted back) I don't
believe the problem is there anyway, but had to cross it off the list.
I've run the software through valgrind with limited information
produced as most of this is happening down the GLw and X libraries.
Does anyone have any ideas on avenues I can pursue to resolve this?
This is killing a lot of my time trying to track this down.
Thank you!
Dennis
> I've run the software through valgrind with limited information
> produced as most of this is happening down the GLw and X libraries.
Sorry, I don't have any experience with OpenGL in Motif.
But I have debugged shared libraries with valgrind and DDD.
In my experience, you can still get good results with Valgrind,
if the libraries in question are not stripped (if they still
contain the symbols, they are several times bigger that way).
Sometimes this does not help, and debugger and/of Valgrid
are still totally lost. In that case, I compile the libraries
myself and statically link them in the main application.
Or I try to switch compilers / debuggers, I use gcc and Intel C compiler.
Intel C/C++ compiler also comes with graphical debugger, which is handy
sometimes when DDD is lost.
Best regards,
Dušan Peterc
http://www.arahne.si
P.S.
Do you know of any sites / books / tutorials which would
help someone use the Motif OpenGL widget in C (not C++)?
Dennis
Try to go back to Motif 2.1.30. Version 2.1 is still the latest official
Motif release. At least, it is the latest version developed through the
traditional, stability-centric Motif development model. The Open Motif
community threw out binary compatibility (and stability) when going to
Open Motif 2.2.
--
Per Espen Hagen
Hi,
I assume there is some reason why you can't upgrade to the 7.x
versions of x.org? Lots of changes there and one would hope that
PrimitiveP.h got updated. If it is still wrong in 7.x, would you
please record a new bug at bugs.openmotif.org? We (the openmotif team)
will work with x.org to get this addressed.
Thanks
Mark