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

NOT OK: perl 5.5.640 on MSWin32-x86-multi-ithread-impsys #1126

Closed
p5pRT opened this issue Feb 3, 2000 · 5 comments
Closed

NOT OK: perl 5.5.640 on MSWin32-x86-multi-ithread-impsys #1126

p5pRT opened this issue Feb 3, 2000 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 3, 2000

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

Searchable as RT2085$

@p5pRT
Copy link
Author

p5pRT commented Feb 3, 2000

From sho_pi@hotmail.com

No, this isn't perlbug generated.

Something about PERL_IMPLICIT_SYS doesn't mix with one or both of
GCC/Mingw32 or Win95 - perl croaks with a "panic​: pad_alloc" the first
time anything tries to allocate a pad slot. I poked around for a while
in gdb and found that somewhere in perl_parse PL_curpad and/or
PL_comppad is getting screwed up.

This doesn't happen with just USE_MULTI and USE_ITHREADS.

this is perl 5.5.640, build with GCC/Mingw32-2.95.2 and -DHAVE_DES_FCRYPT
-DPERL_IMPLICIT_CONTEXT -DUSE_MULTI -DUSE_ITHREADS -DPERL_IMPLICIT_SYS

-- BKS
______________________________________________________
Get Your Private, Free Email at http​://www.hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Feb 12, 2000

From [Unknown Contact. See original ticket]

I wrote earlier this month​:

No, this isn't perlbug generated.

Something about PERL_IMPLICIT_SYS doesn't mix with one or both of
GCC/Mingw32 or Win95 - perl croaks with a "panic​: pad_alloc" the >first
time anything tries to allocate a pad slot. I poked around for >a while in
gdb and found that somewhere in perl_parse PL_curpad
and/or PL_comppad is getting screwed up.

This doesn't happen with just USE_MULTI and USE_ITHREADS.

this is perl 5.5.640, build with GCC/Mingw32-2.95.2 and >-DHAVE_DES_FCRYPT
-DPERL_IMPLICIT_CONTEXT -DUSE_MULTI -DUSE_ITHREADS >-DPERL_IMPLICIT_SYS

I've poked around some more and it actually looks sort of like some kind of
memory corruption - the call to SETERRNO(0, SS$_NORMAL) in perl_parse is
clobbering PL_curpad (!). And, if I try to require a module, the module
compiles (it has a new pad), but the Perl freezes and gdb tells me it's from
a SEGV in pp_const while executing the module. I don't really have the
software to poke much further (at least not without specific guidance) and
gdb crashes itself whenever I try to set a watch. Sigh.

This holds with both USE_ITHREADS/PERL_IMPLICIT_SYS and just
PERL_IMPLICIT_SYS, and I doubt it's Win95-specific, since a copy of Perl
5.5.640+ built with VC++ 4.0 works fine (it takes a few modifications to the
source - 4.0 doesn't have CP_UTF8 or the VC++ equivalent to the -xc++ global
flag, just a file-specific one).

-- BKS
______________________________________________________
Get Your Private, Free Email at http​://www.hotmail.com

1 similar comment
@p5pRT
Copy link
Author

p5pRT commented Feb 12, 2000

From [Unknown Contact. See original ticket]

I wrote earlier this month​:

No, this isn't perlbug generated.

Something about PERL_IMPLICIT_SYS doesn't mix with one or both of
GCC/Mingw32 or Win95 - perl croaks with a "panic​: pad_alloc" the >first
time anything tries to allocate a pad slot. I poked around for >a while in
gdb and found that somewhere in perl_parse PL_curpad
and/or PL_comppad is getting screwed up.

This doesn't happen with just USE_MULTI and USE_ITHREADS.

this is perl 5.5.640, build with GCC/Mingw32-2.95.2 and >-DHAVE_DES_FCRYPT
-DPERL_IMPLICIT_CONTEXT -DUSE_MULTI -DUSE_ITHREADS >-DPERL_IMPLICIT_SYS

I've poked around some more and it actually looks sort of like some kind of
memory corruption - the call to SETERRNO(0, SS$_NORMAL) in perl_parse is
clobbering PL_curpad (!). And, if I try to require a module, the module
compiles (it has a new pad), but the Perl freezes and gdb tells me it's from
a SEGV in pp_const while executing the module. I don't really have the
software to poke much further (at least not without specific guidance) and
gdb crashes itself whenever I try to set a watch. Sigh.

This holds with both USE_ITHREADS/PERL_IMPLICIT_SYS and just
PERL_IMPLICIT_SYS, and I doubt it's Win95-specific, since a copy of Perl
5.5.640+ built with VC++ 4.0 works fine (it takes a few modifications to the
source - 4.0 doesn't have CP_UTF8 or the VC++ equivalent to the -xc++ global
flag, just a file-specific one).

-- BKS
______________________________________________________
Get Your Private, Free Email at http​://www.hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Mar 1, 2000

From [Unknown Contact. See original ticket]

From​: Gurusamy Sarathy <gsar@​ActiveState.com>
To​: "Benjamin Stuhl" <sho_pi@​hotmail.com>
CC​: gsar@​ActiveState.com
Subject​: Re​: [ID 20000203.004] NOT OK​: perl 5.5.640 on
MSWin32-x86-multi-ithread-impsys
Date​: Sat, 19 Feb 2000 07​:00​:30 -0800

On Mon, 14 Feb 2000 13​:38​:11 PST, "Benjamin Stuhl" wrote​:

On Sat, 12 Feb 2000 19​:20​:09 PST, "Benjamin Stuhl" wrote​:

This holds with both USE_ITHREADS/PERL_IMPLICIT_SYS and just
PERL_IMPLICIT_SYS, and I doubt it's Win95-specific, since a copy of
Perl
5.5.640+ built with VC++ 4.0 works fine [...]

Can you retry with 5.5.650? Thanks.

It's still there. All it takes is "perl -e 'my $foo;'" or "perl -e
'qq[foo];'" and Perl dies with a "panic​: pad_alloc".

I can reproduce this under NT here too. It seems like any
C<(*_errno()) = 0> in the source corrupts memory. I was able to
get "print qq[hi]" working by commenting out the SETERRNO() in
S_parse_body(), but there are various other places where errno
is assigned to directly.

Here's a fix for that and some other win32/GCC-Mingw32 nits. The problem was
that GCC was mangling DllMain's name, and so the generic do-nothing DllMain
was being called (it was just coincidence that GCC initializes globals by
default to 0, which happened to be the same value that MSVCRT was getting as
_its_ Tls index.

This patch fixes that, adds some needed prototypes, works around Mingw32's
busted shellapi.h (it doesn't mark CommandLineToArgvW() as WINAPI), removes
miniperl from depending on perlhost.h and v{mem,dir}.h, and removes
-I$(COREDIR) from makefile.mk, as that has consistently caused me problems
when I've been rebuilding miniperl - miniperl has picked up the config.h
from $(COREDIR), not it's default one.

Enjoy!

-- BKS

Offhand, I'd say building C++ objects on win32 is still busted in GCC.
(Building perl in C++ mode with GCC has never gotten a working perl.exe
for me.)

I'd suggest enabling C++ mode build for all the files (instead of
just perllib.c) and see if that gets you anywhere. See change#5129 for
some other fixes I added for the GCC build.

Sarathy
gsar@​ActiveState.com

______________________________________________________
Get Your Private, Free Email at http​://www.hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Mar 1, 2000

From [Unknown Contact. See original ticket]

patch.win32

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