Dealing With Freed Memory Bugs in General in the Interp

[p5pRT]

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

Searchable as RT114566$

[p5pRT]

From @bulk88

Created by @bulk88

Please ignore the perl version in this ticket, I am talking about 5.17 here.

This is a continuation of the discussion/issues I brought up in RT #114496.

In some places, memory is freed, but the pointers are never set to NULL,
potentially causing freed memory bugs. For example S_nuke_stacks.
In other places, like in perl_destruct, Safefrees are followed by NULLing.

At the moment, there is the PERL_POISON flag. Mingw/VC Win32 builds with
DEBUGGING do not currently turn on PERL_POISON. Some of the POSIX smokes,
such as http​://www.nntp.perl.org/group/perl.daily-build.reports/2012/08/msg126373.html
do smoke with PERL_POISON on. I don't know if that is the smoke owner's choice
or its coming from the POSIX Perl build system.

So the issues are, should perl_destruct really be that aggressive in
NULLing out on non-DEBUGGING builds or should it NULL often for perf reasons?

Should perl_destruct or S_nuke_stacks NULL out even more than before
in all build options?

Should Win32 Perls have PERL_POISON on with DEBUGGING/Cfg=Debug so
smoke tests will catch Win32 exclusive bugs such as #114496?

I noticed in RT #114496 that allocating a SV after perl_destruct "worked"
without any superficial errors (segvs/panics). Maybe that is a bug in and
of itself.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.12.3:

Configured by gecko at Wed Feb  9 14:35:46 2011.

Summary of my perl5 (revision 5 version 12 subversion 3) configuration:
   
  Platform:
    osname=MSWin32, osvers=5.2, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT 

-DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS 

-DUSE_PERLIO -D_USE_32BIT_TIME_T -DPERL_MSVCRT_READFIX',
    optimize='-MD -Zi -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='15.0.30729', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf  

-libpath:"C:\Perl\lib\CORE"  -machine:x86'
    libpth=\lib
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib 

advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib ws2_32.lib mpr.lib 

winmm.lib  version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib 

advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib ws2_32.lib mpr.lib 

winmm.lib  version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl512.lib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf  

-libpath:"C:\Perl\lib\CORE"  -machine:x86'

Locally applied patches:
    ACTIVEPERL_LOCAL_PATCHES_ENTRY
    c6fbf28 [perl #71806] perldb does not setup %dbline with the shebang option -d
    1fd8fa4 Add Wolfram Humann to AUTHORS
    f120055 make string-append on win32 100 times faster
    a2a8d15 Define _USE_32BIT_TIME_T for VC6 and VC7
    007cfe1 Don't pretend to support really old VC++ compilers
    6d8f7c9 Get rid of obsolete PerlCRT.dll support
    d956618 Make Term::ReadLine::findConsole fall back to STDIN if /dev/tty can't be opened
    321e50c Escape patch strings before embedding them in patchlevel.h


@INC for perl 5.12.3:
    C:/Perl/site/lib
    C:/Perl/lib
    .


Environment for perl 5.12.3:
    CYGWIN=tty
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    

PATH=C:\Perl\site\bin;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:

\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin;C:\Program Files (x86)\Microsoft 

Visual Studio 9.0\VC;
    PERL_BADLANG (unset)
    PERL_JSON_BACKEND=JSON::XS
    PERL_YAML_BACKEND=YAML
    SHELL (unset)

 		 	   		  

[p5pRT]

From @jkeenan

On Fri, 24 Aug 2012 18​:21​:45 GMT, bulk88 wrote​:

This is a bug report for perl from bulk88@​hotmail.com,
generated with the help of perlbug 1.39 running under perl 5.12.3.

-----------------------------------------------------------------
[Please describe your issue here]

bulk88​: This ticket hasn't garnered a response in 4-1/2 years. I think the questions you raise are valid but would probably benefit from list discussion of specific issues before we handle it through RT. I recommend that we close the ticket.

Please ignore the perl version in this ticket, I am talking about 5.17
here.

This is a continuation of the discussion/issues I brought up in RT
#114496.

In some places, memory is freed, but the pointers are never set to
NULL,
potentially causing freed memory bugs. For example S_nuke_stacks.
In other places, like in perl_destruct, Safefrees are followed by
NULLing.

At the moment, there is the PERL_POISON flag. Mingw/VC Win32 builds
with
DEBUGGING do not currently turn on PERL_POISON. Some of the POSIX
smokes,
such as http​://www.nntp.perl.org/group/perl.daily-
build.reports/2012/08/msg126373.html
do smoke with PERL_POISON on. I don't know if that is the smoke
owner's choice
or its coming from the POSIX Perl build system.

So the issues are, should perl_destruct really be that aggressive in
NULLing out on non-DEBUGGING builds or should it NULL often for perf
reasons?

Should perl_destruct or S_nuke_stacks NULL out even more than before
in all build options?

Should Win32 Perls have PERL_POISON on with DEBUGGING/Cfg=Debug so
smoke tests will catch Win32 exclusive bugs such as #114496?

I noticed in RT #114496 that allocating a SV after perl_destruct
"worked"
without any superficial errors (segvs/panics). Maybe that is a bug in
and
of itself.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

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

[p5pRT]

From @bulk88

On Fri, 17 Feb 2017 13​:58​:50 -0800, jkeenan wrote​:

bulk88​: This ticket hasn't garnered a response in 4-1/2 years. I
think the questions you raise are valid but would probably benefit
from list discussion of specific issues before we handle it through
RT. I recommend that we close the ticket.

Close it. It was a thought exercise.

--
bulk88 ~ bulk88 at hotmail.com

[p5pRT]

From @jkeenan

On Mon, 27 Mar 2017 21​:39​:53 GMT, bulk88 wrote​:

On Fri, 17 Feb 2017 13​:58​:50 -0800, jkeenan wrote​:

bulk88​: This ticket hasn't garnered a response in 4-1/2 years. I
think the questions you raise are valid but would probably benefit
from list discussion of specific issues before we handle it through
RT. I recommend that we close the ticket.

Close it. It was a thought exercise.

Making it so. Thanks for getting back to us.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

@jkeenan - Status changed from 'open' to 'rejected'