Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storable: Cannot restore overloading on SCALAR(0x90e1638) #2958

Closed
p5pRT opened this issue Dec 6, 2000 · 4 comments
Closed

Storable: Cannot restore overloading on SCALAR(0x90e1638) #2958

p5pRT opened this issue Dec 6, 2000 · 4 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Dec 6, 2000

Migrated from rt.perl.org#4864 (status was 'resolved')

Searchable as RT4864$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 6, 2000

From @andk

Created by k@ak-71.mind.de

From time to time I get this error from Storable​:

  Cannot restore overloading on SCALAR(0x90e1638) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/fd_retrieve.al) line 295

It happened just now again with Storable 1.0.6 and perl 5.7.0@​7936
within a mod_perl process which I use with Apache​::Session. When this
happens, I usually just have to reload the page and another mod_perl
process then succeeds in retrieving the very same session file. When I
then cycle through all mod_perl processes and hit the same that failed
before, it works (I mean it is able to read the same session file). It
doesn't happen often. Needless to say that I have no idea how to write
a test case for this error, but I'm increasing the amount of debugging
code for the next time this hits me. Right now I'm not even sure if
the session data contain overloaded scalars but I believe yes.

Any guesses?

This has never, really, really never occurred with Storable 0.603. I
have seen it about since Storable is in the core but didn't report--my
bad.

--
andreas

Perl Info

Flags:
    category=library
    severity=medium

Site configuration information for perl v5.7.0:

Configured by k at Fri Dec  1 05:23:13 CET 2000.

Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2.16a, archname=i686-linux
    uname='linux ak-71.mind.de 2.2.16a #1 smp wed jun 14 11:59:53 cest 2000 i686 unknown '
    config_args='-Dprefix=/usr/local/perl-5.7.0@7936 -Doptimize=-g -des -Dusedevel'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-g',
    cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil
    libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    DEVEL7928


@INC for perl v5.7.0:
    /usr/local/perl-5.7.0@7936/lib/5.7.0/i686-linux
    /usr/local/perl-5.7.0@7936/lib/5.7.0
    /usr/local/perl-5.7.0@7936/lib/site_perl/5.7.0/i686-linux
    /usr/local/perl-5.7.0@7936/lib/site_perl/5.7.0
    /usr/local/perl-5.7.0@7936/lib/site_perl
    .


Environment for perl v5.7.0:
    HOME=/home/k
    LANG=en_US
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/k/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/local/perl/bin:/usr/X11/bin:/sbin:/usr/sbin:/usr/local/Office51/bin
    PERL_BADLANG (unset)
    SHELL=/bin/zsh


@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 6, 2000

From [Unknown Contact. See original ticket]

Quoting Andreas J. Koenig​:
: It happened just now again with Storable 1.0.6 and perl 5.7.0@​7936
: within a mod_perl process which I use with Apache​::Session. When this
: happens, I usually just have to reload the page and another mod_perl
: process then succeeds in retrieving the very same session file. When I
: then cycle through all mod_perl processes and hit the same that failed
: before, it works (I mean it is able to read the same session file). It
: doesn't happen often. Needless to say that I have no idea how to write
: a test case for this error, but I'm increasing the amount of debugging
: code for the next time this hits me. Right now I'm not even sure if
: the session data contain overloaded scalars but I believe yes.
:
: Any guesses?

Yes, it probably means the package defining the overloading magic
was not "require'd" or "use'd" yet, and so Storable has no way to
find the "stash" (or it finds it, but it does not has the proper
magic indicating overloading).

Since the scalar was stored with "overloading" magic, Storable croaks
because it cannot restore it at retrieve time, meaning you would not get
what you stored. A no-no by my book!

Try this patch (compiles, but untested)​:

--- Storable.xs 2000/11/05 17​:21​:24 1.0.1.5
+++ Storable.xs 2000/12/06 18​:59​:20
@​@​ -3375,9 +3377,10 @​@​

  stash = (HV *) SvSTASH (sv);
  if (!stash || !Gv_AMG(stash))
- CROAK(("Cannot restore overloading on %s(0x%"UVxf")",
+ CROAK(("Cannot restore overloading on %s(0x%"UVxf") (package %s)",
  sv_reftype(sv, FALSE),
- PTR2UV(sv)));
+ PTR2UV(sv),
+ stash ? HvNAME(stash) : "<unknown>"));

  SvAMAGIC_on(rv);

It will not make it work, but it should tell you in which package the scalar
expects its magic. Then you will be able to determine whether it was already
require'd or not.

: This has never, really, really never occurred with Storable 0.603. I
: have seen it about since Storable is in the core but didn't report--my
: bad.

No wonder​: overloading was never stored nor retrieved by then. ;-)

Raphael

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 6, 2000

From @andk

On Wed, 6 Dec 2000 20​:02​:07 +0100, Raphael Manfredi <Raphael_Manfredi@​pobox.com> said​:

  > Since the scalar was stored with "overloading" magic, Storable croaks
  > because it cannot restore it at retrieve time, meaning you would not get
  > what you stored. A no-no by my book!

  > Try this patch (compiles, but untested)​:

  > --- Storable.xs 2000/11/05 17​:21​:24 1.0.1.5
  > +++ Storable.xs 2000/12/06 18​:59​:20
  > @​@​ -3375,9 +3377,10 @​@​

  > stash = (HV *) SvSTASH (sv);
  > if (!stash || !Gv_AMG(stash))
  > - CROAK(("Cannot restore overloading on %s(0x%"UVxf")",
  > + CROAK(("Cannot restore overloading on %s(0x%"UVxf") (package %s)",
  > sv_reftype(sv, FALSE),
  > - PTR2UV(sv)));
  > + PTR2UV(sv),
  > + stash ? HvNAME(stash) : "<unknown>"));

  > SvAMAGIC_on(rv);

  > It will not make it work, but it should tell you in which package the scalar
  > expects its magic. Then you will be able to determine whether it was already
  > require'd or not.

This is a great patch and now I also know how to reproduce it​: setting
MaxRequestPerChild to a low value. Because then we more often than
usual we talk to a child that has not yet loaded the associated magic
because it is a "virgin" module. With your patch I get​:

  Cannot restore overloading on SCALAR(0x90dab14) (package URI​::http) at
  blib/lib/Storable.pm (autosplit into
  blib/lib/auto/Storable/fd_retrieve.al) line 297, at
  /usr/local/apache/lib/map_box/aplan.pm line 552

which clearly indicates what I have to do before trying to retrieve
the session.

  > : This has never, really, really never occurred with Storable 0.603. I
  > : have seen it about since Storable is in the core but didn't report--my
  > : bad.

  > No wonder​: overloading was never stored nor retrieved by then. ;-)

;-)

Thanks!

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 21, 2000

From The RT System itself

The patch will be in the next Storable release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant