On Wed, 2010-07-14 at 12:43 +1000, Nathan Scott wrote:
> ----- "Nathan Scott" <nathans@xxxxxxxxxx> wrote:
>
> > ----- "Nathan Scott" <nathans@xxxxxxxxxx> wrote:
> >
> > > Not there yet, but closing in on it. Couple of things that may
> > help,
> >
> > Its definately timezone related - descending deeper, we can see its
> > something to do with the __pmSquashTZ call - if I set TZ in the env
> > (and hence skip that call inside __pmLogCreate + __pmTimezone) when
> > running the script, everything works...
>
> If I comment out the call to "putenv(tzbuffer);" at libpcp/tz.c, line
> 126 ... all is well. Hmmm ... thats ... odd. Any theories? Possible
> workaround to this odd libpcp/perl-runtime interaction might be to set
> the TZ variable yourself before calling __pmLogCreate...? Bit of a
> hack, but anything else is going to require libpcp changes I suspect.
OK, you've got as far as I did ... which is good, 'cause it means there
is not some obvious snarfoo in the Perl wrapper code.
tzbuffer is a static and it does not really need to be ... we could
malloc it and let it leak (or stay in the environment) ... I'll poke
around a bit in that area.
What remains a complete mystery is why/how the perl_destruct() routine
finds out about this address at all when it does not leak back through
the API wrapper into Perl-land ... which supports your (and my) original
hypothesis that this is really a Perl stack corruption issue associated
with the call and args from Perl or the return values to Perl, but alas
we have not smoking gun there.
Cheers and thanks.
|