S2 constant errors

[kareila]

With global warnings on, some permutation of these lines shows up in the log whenever I hit an S2 page:

Constant subroutine S2::PROPS redefined at /usr/share/perl/5.8/constant.pm line 103.
Constant subroutine S2::STATIC redefined at /usr/share/perl/5.8/constant.pm line 103.
Constant subroutine S2::VTABLE redefined at /usr/share/perl/5.8/constant.pm line 103.

Any ideas as to why this might be happening?

Comments

[fu]

Hmm, okay so, I tried looking up "constant subroutine" in man perldiag which told me to look at the "Constant Functions" section in man perlsub.

And I think that what that means is that since constants are inlined for efficiency, redefining the constant on the fly, won't update the places it had previously been inlined into at compile-time.

We could silence it in the same way that we silence "Subroutine redefined" in Apache::LiveJournal, but, assuming that what my understanding in the second paragraph is correct, this might result in some strange behavior, until we restart apache.

Another alternative: silence the warnings, but if a constant may have been redefined because its file was reloaded, print out one warning "Constants may have been redefined; restart web server" or something? It only affects dev servers so we can afford to restart servers as much as wanted.

[kareila]

Is it not possible to avoid redefining the constants in the first place? I mean, if they're constants, we shouldn't be trying to change them. As it is, even if we compress the warnings to one line, that line would still be printed every time we load an S2 page, which is gratuitous even for a dev server.

[alierak]

If I understand fu correctly, they're only defined once in all the code, but an Apache process that stays running for a while may read a new version of the code, containing a new definition of the constants. If that's the case, restarting Apache should make it quit warning you.

[kareila]

I think it's happening when S2 layers are loaded (see my new comment below).

[fu]

I think it's any constants at all, when the file is reloaded (and we could do it one check per set of files to be reloaded in a request, which will make things a lot less verbose)

You can see it if you, e.g., touch $LJHOME/cgi-bin/DW/InviteCodes.pm; when that is reloaded, you get all the warnings about the constants in there.

[kareila]

I am starting to suspect this code in s2/S2/BackendPerl.pm:

$io->writeln("package S2;");
$io->writeln("use strict;");
$io->writeln("use constant VTABLE => 0;");
$io->writeln("use constant STATIC => 1;");
$io->writeln("use constant PROPS => 2;");
$io->writeln("register_layer($this->{'layerID'});");

I think that results in the constants being redefined every time an S2 layer is loaded? Removing the lines had no immediate effect; I think all the layers would have to be recompiled as well?

[andy]

I guess these lines can just be moved to S2.pm, no?

[kareila]

Uh, they're already in S2.pm.

Edit: which is to say, yes, since they're there, I wouldn't see any harm with removing the lines from BackendPerl.pm. But when I tried that, the warnings didn't disappear immediately.

[andy]

You will need to recompile all styles on your dev server, obviously. Issue bin/upgrading/update-db.pl --help and go from there, the appropriate flags would be -f -p, but I'm unsure.

[kareila]

From decoding the GetOptions call, it looks like --forcebuild (not listed in --help). But thanks for the pointer.

So after trying that, I'm still seeing the redefined constants twice per S2 lastn page call and once per every other S2 page call. Since S2.pm is loaded in LJ::S2 and LJ::S2::EntryPage, I think they are still being reloaded by mod_perl every time, even though the files haven't changed.

[kareila]

Hmm, does update-db.pl recompile the user layers as well, or only the system layers? If the existing user layer still tries to redefine the constants, that might also affect what I'm seeing.

[kareila]

alierak executed this SQL query to fix the user layers:

update s2compiled2 set compdata=replace(compdata,'use constant VTABLE => 0;\nuse constant STATIC => 1;\nuse constant PROPS => 2;\n','');

That seems to have done the trick, phew.