Bug #75024 for Astro-FITS-CFITSIO: ffgkls() frees to wrong pool on MS Windows

Wed Feb 15 06:46:39 2012 sisyphus [...] cpan.org - Ticket created

CC:	pratzlaff [...] cfa.harvard.edu
Subject:	ffgkls() frees to wrong pool on MS Windows

Hi, The ffgkls function produces a "Free to wrong pool..." error on MS Windows. As I understand it, 'free' currently calls 'PerlMem_free', but we need the system 'free' to be called. This small patch to CFITSIO.xs removes the error: ######################################## --- CFITSIO.xs_orig 2012-02-15 22:01:33 +1100 +++ CFITSIO.xs 2012-02-15 22:02:39 +1100 @@ -7655,6 +7655,9 @@ comment=(ST(3)!=&PL_sv_undef) ? get_mortalspace(FLEN_COMMENT,TBYTE) : NULL; RETVAL=ffgkls(fptr,keyname,&longstr,comment,&status); sv_setpv(ST(2),longstr); +#ifdef WIN32 +#undef free +#endif free(longstr); OUTPUT: comment ######################################## Cheers, Rob

Wed Feb 15 13:37:22 2012 pratzlaff [...] cfa.harvard.edu - Correspondence added

CC:	sisyphus [...] cpan.org
Subject:	Re: [rt.cpan.org #75024] ffgkls() frees to wrong pool on MS Windows
Date:	Wed, 15 Feb 2012 13:37:05 -0500
To:	bug-Astro-FITS-CFITSIO [...] rt.cpan.org
From:	Peter Ratzlaff <pratzlaff [...] cfa.harvard.edu>

Thanks very much for letting me know about this problem. There are a number of places in CFITSIO.xs where the interface to cfitsio requires calling free(3), and a couple more where malloc/free are paired up for temporary storage. So it seems like the best solution might be the following patch. Could you give it a try on Win32 and let me know if there are any unanticipated effects? --- CFITSIO.xs 19 Jan 2012 19:47:56 -0000 1.51 +++ CFITSIO.xs 15 Feb 2012 18:30:29 -0000 @@ -11,6 +11,14 @@ #include "fitsio.h" #include "util.h" +/* use the C std lib malloc/free */ +#ifdef malloc +#undef malloc +#endif +#ifdef free +#undef free +#endif + On 02/15/2012 06:46 AM, Sisyphus via RT wrote: Show quoted text

> Wed Feb 15 06:46:39 2012: Request 75024 was acted upon. > Transaction: Ticket created by SISYPHUS > Queue: Astro-FITS-CFITSIO > Subject: ffgkls() frees to wrong pool on MS Windows > Broken in: 1.08 > Severity: Normal > Owner: Nobody > Requestors: sisyphus@cpan.org > Status: new > Ticket<URL: https://rt.cpan.org/Ticket/Display.html?id=75024> > > > Hi, > > The ffgkls function produces a "Free to wrong pool..." error on MS Windows. > > As I understand it, 'free' currently calls 'PerlMem_free', but we need > the system 'free' to be called. > > This small patch to CFITSIO.xs removes the error: > > ######################################## > --- CFITSIO.xs_orig 2012-02-15 22:01:33 +1100 > +++ CFITSIO.xs 2012-02-15 22:02:39 +1100 > @@ -7655,6 +7655,9 @@ > comment=(ST(3)!=&PL_sv_undef) ? get_mortalspace(FLEN_COMMENT,TBYTE) : > NULL; > RETVAL=ffgkls(fptr,keyname,&longstr,comment,&status); > sv_setpv(ST(2),longstr); > +#ifdef WIN32 > +#undef free > +#endif > free(longstr); > OUTPUT: > comment > ######################################## > > Cheers, > Rob

Wed Feb 15 13:37:22 2012 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 15 19:49:32 2012 sisyphus [...] cpan.org - Correspondence added

On Wed Feb 15 13:37:22 2012, PRATZLAFF wrote: Show quoted text

> Thanks very much for letting me know about this problem. There are a > number of places in CFITSIO.xs where the interface to cfitsio requires > calling free(3), and a couple more where malloc/free are paired up for > temporary storage.

Yes, I noticed that. Those "other" cases didn't pose any problems (that the test suite detected, at least) so I left them as is. Your patch is fine - no unwanted ramifications detected. I didn't mention this earlier, but the following tests fail: ffirec/ffikyX..........................not ok ffmrec/ffmcrd/ffmnam/ffmcom/ffmkyX.....not ok ffucrd/ffukyX..........................not ok ffgnxk.................................not ok ffgtbb.................................not ok The other 144 tests all pass. The version of perl being used doesn't make any difference to the pass statistics - I built on 5.8.0, 5.8.9, 5.10.0, 5.12.0 and 5.14.0 (both 32-bit and 64-bit for the last 3) and I think they all report the same 5 failures. (I haven't yet even thought about what might be causing those failures.) Anyway - if I need some help, I'll probably raise these failures (and a failure in Astro::FITS::Header's t/cfitsio.t) on the PDL porters mailing list. Are you subscribed to that mailing list, or should I cc you ? Cheers, Rob