Re: [Plplot-devel] Problem builiding the Python bindings on Windows using MS VC/C++

[Arjen M. <Arj...@de...>]

Hi Alan,


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, October 19, 2013 6:50 PM
> To: Arjen Markus
> Cc: PLplot development list; Andrew Ross
> Subject: RE: [Plplot-devel] Problem builiding the Python bindings on Windows using
> MS VC/C++
>
> Hi Arjen:
>
> Thanks very much for running the Python-C comparisons for both MinGW/MSYS
> (and later) MSVC on 32-bit Windows.  More below in context.

...
>
>
> My working hypothesis to explain this unusual result is some memory management
> issue (e.g., an uninitialized variable) in our core C library and/or our ps device that
> generates some unpredictability in the results.  A further hypothesis is that Python
> has a very large memory footprint so it leaves non-zero bit patterns behind scattered
> over a wide memory space, and one of those non-zero bit patterns is being
> interpreted differently by the uninitialized variable than when any other language is
> being used to run the examples.
>
> In later e-mail concerning the MSVC case you stated the following
> results:
>
> <quote>
> - Most of the Python examples produce the same results as the corresponding C
> examples.
>
> - The ones that do not simply crash at some point. These are: 08, 09, 11, 15, 16, 20,
> 21 and 22.
>    I have not looked into the possible cause of this. It may be a single function that is
> causing this.
>    It may be a set of functions.
>
>    Anyway, this means that the mystery is only larger: The Python installation was
> _exactly_ the same under Windows/MSVC as under Windows/MinGW.
> </quote>
>
> I think these results are also consistent with the working hypothesis that there is a
> lurking memory management issue in our core C library and/or the ps device driver
> code for the 32-bit case.
>
> So Arjen, if you have access to a static or dynamic memory debugging tool for
> Windows (see a partial list of such tools for all operating systems at
> http://en.wikipedia.org/wiki/Memory_debugging), I suggest you run it on x00c (our
> simplest 2D plot example written in C) to see if it spots some memory management
> issue (uninitialized variable or
> whatever) in libplplotd, our core C library.  And, of course, if MinGW or MSVC is
> giving any warning messages at all concerning the compilation of our core C library,
> we should try to address those warnings.
>

Well, the fact that I now get perfectly matching results for Python and C under Windows/MSVC,
means that the likelihood of an uninitialised variable/memory location is strongly reduced. The
crashes were simply my mistake.

I did notice a number of warnings while building the libraries and examples and it is worthwhile
to examine those. (There is also the Java issue for this platform.)

Debugging is going to be tough: I can not build with the Debug build type because of the Python
problem I mentioned. This means I would have to try and debug an executable that is not built
for debugging. Hm, the MinGW platform does allow the Debug build, maybe that is a possibility.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.