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

Consting the core magic vtables breaks mod_perl #14450

Closed
p5pRT opened this issue Jan 28, 2015 · 6 comments
Closed

Consting the core magic vtables breaks mod_perl #14450

p5pRT opened this issue Jan 28, 2015 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 28, 2015

Migrated from rt.perl.org#123687 (status was 'rejected')

Searchable as RT123687$

@p5pRT
Copy link
Author

p5pRT commented Jan 28, 2015

From @steve-m-hay

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...

@p5pRT
Copy link
Author

p5pRT commented Jan 28, 2015

From @Leont

On Wed, Jan 28, 2015 at 2​:30 AM, Steve Hay <perlbug-followup@​perl.org>
wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Jan 28, 2015

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jan 29, 2015

From @bulk88

Leon Timmermans wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Feb 6, 2015

From @steve-m-hay

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.

@p5pRT
Copy link
Author

p5pRT commented Feb 6, 2015

@steve-m-hay - Status changed from 'open' to 'rejected'

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

No branches or pull requests

1 participant