Does Item #1 mean the first list element returned by STORABLE_freeze? return $serialized, $self->{locale}, $self->{tz}, \$self->{formatter};
Because, indeed it isn't a reference, but a scalar. I have some code that is serializing items that have DateTime objects (of course) and I'm seeing that message when running my test suite. I added this line above that line above in DateTime: warn ">>>>$serialized\n"; And running my tests I see: >>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401 >>>>utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401 ok 6 - Fetched expected key >>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401 >>>>utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401 >>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401 >>>>utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401 ok 7 - Fetched data matches >>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401 (in cleanup) Item #1 returned by STORABLE_freeze for DateTime is not a reference at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_freeze.al) line 339 during global destruction, at <....> line 327 Line 327 is my $serialized = nfreeze( $data ); I'm a bit confused why it's only complaining on the last one -- STORABLE_freeze is seemingly returning the same (scalar) data. It's expected that this nfreeze is happening in a DESTROY() (the data gets serialized and stored upon destroy). Is the destroy a red herring? -- Bill Moseley mose...@hank.org