On Sat, Mar 6, 2010 at 7:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 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:
>>
>>> 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>
>
The times I have faced similar issues, it has been from "full stack"
Gtk applications, where Gtk is managing the full GUI, rather than
having Gtk components pieced together inside another GUI provider
("raw" X in the case of xcairo). But, based on your results and some
further valgrind testing of my own, I don't think that is the issue
any more.
> 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.
>
< working Gnome/Gtk results... >
eog should be a perfect test, and since that didn't have similar
issues X-forwarding troubles seem to be ruled out. That's good since
it is (apparently) not a problem with your system, and bad because it
means it's a problem in the PLplot OCaml stack! :-)
>> 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 am still mostly convinced, or at least hopeful, that Lenny should be
able to support this. Your valgrind results, as unfortunate as they
are, show some promise for a fix (see below).
>>
>> 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.... :-) )
>
64-bit hardware (Intel in this case) and OS here as well :-)
> 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.
>
I tried x01ocaml (ocamlopt-compiled) with valgrind and got similar
results to what you report. However, I get clean valgrind results
when compiling the x01.ml manually like so:
ocamlfind opt -package plplot -linkpkg x01.ml -o x01ocaml.opt
It may be best if you copied x01.ml to a separate directory as the
compilation will leave some intermediate files behind. From here,
running:
valgrind ./x01ocaml.opt
gives clean results, with no double-free or similar errors on my
system. Could you test this as well?
This leads me to believe that there may be something wrong with our
CMake + OCaml build infrastructure. This is probably a good time to
take a look at the recent OCaml CMake module development occurring on
the CMake list.
If I/we are unable to find an issue in the build system then I will
install Debian Lenny under a VM on my system and see if I can
reproduce your results directly.
Best of luck in getting your email access back! :-)
Hez
------------------------------------------------------------------------------
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
