On 2010-03-06 17:24-0500 Hezekiah M. Carty wrote:
On Sat, Mar 6, 2010 at 4:11 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
I thought your idea was a winner, but unfortunately the evidence is against
that because the "direct" test got identical error messages except for the
process id, (I checked that thoroughly by using sed to change back to the
process id of the original set of messages.) I even played with xhost to
allow the local host to connect to the server (which is redundant and should
definitely not be needed), and still got the same set of error messages.
Drat. There goes the simple option!
:-)
What exactly did you mean by Gtk-using applications?
Any application which uses Gtk for its GUI. Any Gnome application
would fall under this, as would the Gimp. I'm not sure if anything
that isn't deprecated in PLplot uses Gtk from C. Could you try
running Gimp or another Gtk-based GUI application from the same
command-line environment you are running xgtk_interfaceocaml from?
Everything I have read so far points to an X permissions issue. I
unfortunately only have access to one system at the moment, so I can't
do much in the way of testing.
-dev xcairo and all our other interactive tests run by the test_interactive
target work fine for me (via the X-terminal and directly). I haven't tried
gcw recently (it is disabled by default), but it hasn't been an issue
when I tried it before.
xcairo uses X libraries directly, so if this is a Gtk issue then it
shouldn't affect the xcairo device on its own.
<aside> That's not the complete story. Our cairo devices use a large
fraction of the lower part of the libGTK+ stack, i.e., pango, cairo,
fontconfig, and eventually (for xcairo) X. There is more to the complete
GTK+ stack of libraries than libGTK+ and the stack of libraries we use for
xcairo, but not a lot more. </aside>
However, that issue aside it is still worth verifying that permissions are
not a problem for applications that depend on the _full_ libGTK+ stack.
Such an application is eog (Eye of GNOME image viewer). ldd shows (as
expected) it depends on the GTK+ library.
softw...@raven> ldd /usr/bin/eog |grep -i gtk
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007fb13c79c000)
Similarly, for gucharmap (a GNOME system glyph viewer) we have
softw...@raven> ldd /usr/bin/gucharmap |grep -i gtk
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f3dcf926000)
There were no permission problems at all on my X-terminal when using either
app from the softw...@raven account where I produced the bad
xgtk_interfaceocaml results! And certainly those apps had no such X
permission problems for the "direct" approach using that same account. I am
not sure whether root account has a say about X permissions, but just as an
experiment I ran xgtk_interfaceocaml as root both on the X-terminal and the
"direct" system. Both errored out in the same way (verified with sed editing
of the proc ID) as my original attachment!
While I am currently using lablgtk 2.12.0, I originally developed this
example while using 2.10.1 and I have not updated the example since
then, so that should not be an issue. xgtk_interfaceocaml only uses a
few very basic Gtk calls to setup the window and its contents so even
very old versions of Gtk and lablgtk should be sufficient for that
example to function. Debian Lenny should certainly be modern enough
to handle this.
So much for that idea.... :-)
I will dig in to this some more if other Gtk applications do not show
similar results on your system. I may be able to setup an old desktop
for testing if I can find a working keyboard and mouse to go with it.
I just tried using ("direct") valgrind and have attached the
results. Notice the error messages "Fatal error: exception Out_of_memory"
and "Invalid free() / delete / delete[]"
which are obviously quite serious. I also get the latter issue from
x01ocaml. So I wonder if I have a bad ocaml stack of some kind where I
am playing with fire but with the "Invalid free() / delete / delete[]" being
inconsequential by chance for the standard examples, but causing
(again by chance) the xgtk_interfaceocaml app to get clobbered by
Out_of_memory?
I did some partial testing of my ocaml stack by introducing a FORCE_OCAMLC
option (which defaults to OFF) for our build system. When that is turned
ON, ocamlopt is not even looked for which forces use of ocamlc instead.
That turned up a dependency issue for the OCAMLOPT false case which I fixed
(revision 10858). I then ran the example created with ocamlc (I verified
with the VERBOSE=1 option that ocamlopt was used nowhere in that build) with
the same errors resulting. However, the valgrind messages were a bit
different. Instead of the exact message from above , there was a slight
variation "Fatal error: out of memory". The ""Invalid free() / delete /
delete[]" was there, but it was also obvious from the valgrind call list
that an interpreter was involved when running the application (consistent
with the man pages of ocamlc and ocamlopt where the former generates a
self-running bang script that interprets byte-code while the latter produces
a native-Unix executable.
I also wonder if it is a 64-bit issue? (My hardware is 64-bit, i.e.,
AMD-64). (The way our verification luck is running, you will have 64-bit
hardware also.... :-) )
Anyhow, my valgrind results give us lots of food for thought here (not only
for xgtk_interfaceocaml but also the standard ocaml examples as well). I
hope you will also run valgrind (for both the default -DFORCE_OCAMLC=OFF and
-DFORCE_OCAMLC=ON) to see what memory management issues are revealed on your
system.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________==32707== Memcheck, a memory error detector.
==32707== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==32707== Using LibVEX rev 1854, a library for dynamic binary translation.
==32707== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==32707== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.
==32707== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==32707== For more details, rerun with: -v
==32707==
Fatal error: exception Out_of_memory
==32707== Invalid free() / delete / delete[]
==32707== at 0x4C2130F: free (vg_replace_malloc.c:323)
==32707== by 0x753B7AA: (within /lib/libc-2.7.so)
==32707== by 0x753B361: __libc_freeres (in /lib/libc-2.7.so)
==32707== by 0x4A1D31C: _vgnU_freeres (vg_preloaded.c:60)
==32707== by 0x746AA44: exit (in /lib/libc-2.7.so)
==32707== by 0x4B3C0F: caml_fatal_uncaught_exception (in
/home/software/plplot_svn/HEAD/build_dir/examples/ocaml/xgtk_interfaceocaml)
==32707== by 0x4A73FD: caml_main (in
/home/software/plplot_svn/HEAD/build_dir/examples/ocaml/xgtk_interfaceocaml)
==32707== by 0x4A741F: main (in
/home/software/plplot_svn/HEAD/build_dir/examples/ocaml/xgtk_interfaceocaml)
==32707== Address 0x403f648 is not stack'd, malloc'd or (recently) free'd
==32707==
==32707== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 8 from 1)
==32707== malloc/free: in use at exit: 524,742 bytes in 758 blocks.
==32707== malloc/free: 1,040 allocs, 287 frees, 876,980 bytes allocated.
==32707== For counts of detected errors, rerun with: -v
==32707== searching for pointers to 758 not-freed blocks.
==32707== checked 1,903,360 bytes.
==32707==
==32707== LEAK SUMMARY:
==32707== definitely lost: 120 bytes in 1 blocks.
==32707== possibly lost: 1,600 bytes in 20 blocks.
==32707== still reachable: 523,022 bytes in 737 blocks.
==32707== suppressed: 0 bytes in 0 blocks.
==32707== Rerun with --leak-check=full to see details of leaked memory.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
