Skip Menu |
Report information
Id: 123687
Status: rejected
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: shay <steve.m.hay [at] googlemail.com>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: Consting the core magic vtables breaks mod_perl
Download (untitled) / with headers
text/plain 809b
The following commit causes mod_perl (svn trunk) to fail on startup (on Windows, at least) using 5.21.8: http://perl5.git.perl.org/perl.git/commit/c910fead78 It works fine on the same system (VC++ 2010, with httpd-2.4.10) using 5.21.7. I get an access violation in modperl_env_init() when trying to replace the now const PL_vtbls with its own versions: void modperl_env_init(void) { /* save originals */ StructCopy(&PL_vtbl_env, &MP_PERL_vtbl_env, MGVTBL); StructCopy(&PL_vtbl_envelem, &MP_PERL_vtbl_envelem, MGVTBL); /* replace with our versions */ StructCopy(&MP_vtbl_env, &PL_vtbl_env, MGVTBL); StructCopy(&MP_vtbl_envelem, &PL_vtbl_envelem, MGVTBL); } Is this diddling with perl's globals an unreasonable thing for mod_perl to be trying to do? I fear the answer may be yes...
Date: Wed, 28 Jan 2015 02:41:54 +0100
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Subject: Re: [perl #123687] Consting the core magic vtables breaks mod_perl
To: Perl5 Porters <perl5-porters [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Jan 28, 2015 at 2:30 AM, Steve Hay <perlbug-followup@perl.org> wrote:
Show quoted text
The following commit causes mod_perl (svn trunk) to fail on startup (on Windows, at least) using 5.21.8:

http://perl5.git.perl.org/perl.git/commit/c910fead78

It works fine on the same system (VC++ 2010, with httpd-2.4.10) using 5.21.7.

I get an access violation in modperl_env_init() when trying to replace the now const PL_vtbls with its own versions:

void modperl_env_init(void)
{
    /* save originals */
    StructCopy(&PL_vtbl_env, &MP_PERL_vtbl_env, MGVTBL);
    StructCopy(&PL_vtbl_envelem, &MP_PERL_vtbl_envelem, MGVTBL);

    /* replace with our versions */
    StructCopy(&MP_vtbl_env, &PL_vtbl_env, MGVTBL);
    StructCopy(&MP_vtbl_envelem, &PL_vtbl_envelem, MGVTBL);
}

Is this diddling with perl's globals an unreasonable thing for mod_perl to be trying to do? I fear the answer may be yes...

Yes, I think overwriting the vtables is unreasonable. What I think is more reasonable (but still not completely reasonable or sane) is to lookup %ENV's magic, and then replace the pointer to PL_vtbl_env with a pointer to MP_vtbl_env. You may have to add some svt_copy magic to make it cast MP_vtbl_envelem instead of PL_vtbl_envelem on the elements.

Leon
Date: Thu, 29 Jan 2015 02:25:31 -0500
From: bulk88 <bulk88 [...] hotmail.com>
To: Leon Timmermans <fawaka [...] gmail.com>
CC: Perl5 Porters <perl5-porters [...] perl.org>, "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Subject: Re: [perl #123687] Consting the core magic vtables breaks mod_perl
Download (untitled) / with headers
text/plain 2.5k
Leon Timmermans wrote: Show quoted text
> Yes, I think overwriting the vtables is unreasonable. What I think is > more reasonable (but still not completely reasonable or sane) is to > lookup %ENV's magic, and then replace the pointer to PL_vtbl_env with a > pointer to MP_vtbl_env. You may have to add some svt_copy magic to make > it cast MP_vtbl_envelem instead of PL_vtbl_envelem on the elements. > > Leon
All of that plus. Perl mg vtable ptrs are basically GUIDs. Even if all members in the vtable are 0, it serves to separate classes/modules from other classes/modules (unless the CC deduped things, but MSVC only dedups functions and string literals, not const named global vars). Perl originally had just the U8/I8 "how"/"mg_type" to separate MGs. 2 were reserved for extensions, 'U' and '~'. At some point someone invented to use the vtable ptrs to separate all the ~ magic. My (MSVC) C debugger shows symbol names of pointers if they are global/static allocated C vars, if I inspect a struct. In examining a crash dump, to see a foreign pointer, means it is time to track down that foreign pointer. A perl core/interp C global var ptr will always be between 0x2800,0000-0x2820,0000 on Win32 Perl (Sarathy picked 0x28000000 a very long time ago with no comments in git history why). If the pointer isn't in that range, then it is malloced or from a XS DLL. So if a module wants its own tied/magic %ENV, replace the existing PL_vtbl* ptr with its own MP_vtbl* symbol (possibly with copied over fnc ptr from the previous PL_vtbl* struct), this way in examining a crash dump, you know this magic hash/SV is owned/maintained by modperl and not p5p since it will have a MP_vtbl* prefix in the C debugger instead of a PL_vtbl* symbol. Checking for patching of the core vtbl will require 1 or 2 more clicks, to look inside PL_vtbl* struct, and see the C function name symbols of those pointers, which is a tiny bit more work. Further commenting, since MS is closed source and has1 developer, Win32 Kernel uses 4 byte integers, that happen to always be printable ASCII, to identify memory allocation types. "Allocation types" in other words are classes/objects, but Win32 kernel is plain C, so "classes" is a fuzzy word. http://alter.org.ua/docs/win/pooltag/ . But to pull off pool tags requires exactly 1 person to hand them out and maintain a registry like domain names have, which is difficult with FOSS, but easy inside 1 company (MS). Perl's mg vtable ptrs seem to be unique enough, and expanding mg_type from char to U32 seems like a waste at this point in the history of Perl.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 159b
Thanks for the replies. I've raised a mod_perl ticket for this instead now: https://rt.cpan.org/Ticket/Display.html?id=101962 so am closing this perl ticket.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org