my @vals=(\@someArray,\%someHash);
      my $res=store(\@vals,"$path/$name");
[download]

  my @someArray = ();
  my %someHash = ();
  my $res=retrieve("$path/$name");
  if($res) {
    my ($tmp1, $tmp2) = @$res;
    if($tmp1) {
      @someArray = @$tmp1;
    }
    if($tmp2) {
      %someHash = %$tmp2;
    }
  }
[download]

WRITE(header, length);
[download]

WRITE( (unsigned char*) header, length);
[download]

#define WRITE(x,y)                             \
  STMT_START {                                \
    if (!cxt->fio)                            \
        MBUF_WRITE(x,y);                    \
    else if (PerlIO_write(cxt->fio, x, y) != y)    \
        return -1;                            \
  } STMT_END
[download]

I was under the impression that you cannot (err, should not) upgrade Storable without upgrading Perl at the same time.. Is that not the case?..

That is not the case. I upgrade core (albeit generally only ones which are distributed separately on CPAN) modules every day and so should you (for example, File::Spec is continually being improved).

...my $res=retrieve("$path/$name");...

It could very well be that $path/$name is corrupt somehow, but how would anyone except you reproduce that?

I started doing diff on storable.xs and am pretty sure that it must be ...

Um, yeah, whatever. Did you try your code with the newest storable? Did it work? Did you try regenerating $path/$name? Does it still break (with the newest storable)? If you still can't get it to work try contacting the perl Storable people (perl5-porters at at at at at at at at at at at at at at at at at at at perl.org), and be sure to send them a self-contained snippet which reproduces the bug (including a copy of your storable file).

Good luck

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

Just a few comments:

I don't think that $path/$name is corrupt because it would never get into this code area if there were a problem with either $path or $name (I.E. $path has to be a directory which is writable and $name has to be a valid filename).

As I may have forgotten to mention: this is not a reproducable bug.. It happens very rarely and I've been unsuccessful in creating some snippet which would reproduce it...

As for the "umm, yeah, whatever" comment: Some of us aren't avid C programmers and we do the best we can with what we know. If there is something else that I could do or some piece of information I could provide please let me know, but please if you are going to dis my attempt at least tell me why you are doing so. Is it so useless to look at changes between versions to try and find some evidence that your bug was resolved?

Also, is it at all noteworthy that this is happening in perl_destruct, or is that rather inconsequential to the issue?...

I will certainly send this on to the Perl folks, at any rate, if no resolution can be found here.... For some reason I get a queasy feeling about upgrading Storable... I'd at least like to be able to point at some code that changed which is likely to have solved this problem before doing it.....

- Greg