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

Dealing With Freed Memory Bugs in General in the Interp #12347

Closed
p5pRT opened this issue Aug 24, 2012 · 6 comments
Closed

Dealing With Freed Memory Bugs in General in the Interp #12347

p5pRT opened this issue Aug 24, 2012 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented Aug 24, 2012

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

Searchable as RT114566$

@p5pRT
Copy link
Author

p5pRT commented Aug 24, 2012

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
Copy link
Author

p5pRT commented Feb 17, 2017

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
Copy link
Author

p5pRT commented Feb 17, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Mar 27, 2017

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
Copy link
Author

p5pRT commented Mar 27, 2017

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
Copy link
Author

p5pRT commented Mar 27, 2017

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

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

No branches or pull requests

1 participant