develooper Front page | perl.perl5.porters | Postings from August 2016

[perl #129027] null pointer deref Perl_mess_sv (util.c:1508)

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
August 25, 2016 20:43
Subject:
[perl #129027] null pointer deref Perl_mess_sv (util.c:1508)
Message ID:
rt-4.0.24-30622-1472157799-306.129027-15-0@perl.org
On Thu Aug 25 06:58:45 2016, dcollinsn@gmail.com wrote:
> Looks to me like the following patch is enough to resolve this issue.
> Valgrind is clean, and no failures with make test.
> 
> From 76d06fab84e6fdc64a1c24a335bbd3f40ee4a32e Mon Sep 17 00:00:00 2001
> From: Dan Collins <dcollinsn@gmail.com>
> Date: Thu, 25 Aug 2016 09:54:49 -0400
> Subject: [PATCH] RT #129027: Null pointer check
> 
> ---
> util.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/util.c b/util.c
> index 7748c6c..17dd69c 100644
> --- a/util.c
> +++ b/util.c
> @@ -1504,6 +1504,7 @@ Perl_mess_sv(pTHX_ SV *basemsg, bool consume)
>          * from the sibling of PL_curcop.
>          */
> 
> +        if (PL_curcop) {
>         const COP *cop =
>             closest_cop(PL_curcop, OpSIBLING(PL_curcop), PL_op,
> FALSE);
>         if (!cop)
> @@ -1512,6 +1513,8 @@ Perl_mess_sv(pTHX_ SV *basemsg, bool consume)
>         if (CopLINE(cop))
>             Perl_sv_catpvf(aTHX_ sv, " at %s line %"IVdf,
>             OutCopFILE(cop), (IV)CopLINE(cop));
> +        }
> +
>         /* Seems that GvIO() can be untrustworthy during global
> destruction. */
>         if (GvIO(PL_last_in_gv) && (SvTYPE(GvIOp(PL_last_in_gv)) ==
> SVt_PVIO)
>                 && IoLINES(GvIOp(PL_last_in_gv)))
> --
> 2.8.1
> 
> Thoughts? (Should there be a PL_curcop here, or is it OK for it to be
> null? I found this old thread which may be relevant:
> http://www.nntp.perl.org/group/perl.perl5.porters/2013/08/msg205604.html
> )

Yes, it is relevant.  The backtrace shows that the PL_curcop is being read when ops are being freed.  One of those ops is almost certainly a cop (too lazy to check) which happened to be PL_curcop, so freeing it set PL_curcop to null.

I do wonder, though, whether we should be adding more conditions to normal code for the sake of debugging code.  That said, errors and warnings are certainly not hot code, so your fix, the simpler fix, is probably fine.

(gdb) bt
#0  0x000000010020299a in Perl_mess_sv (my_perl=0x100803200, basemsg=0x1008308f8, consume=1 '\001') at util.c:1508
#1  0x0000000100203f58 in Perl_vmess (my_perl=0x100803200, pat=0x10056d800 "free op at %p, recorded in slab %p", args=0x7fff5fbfd4d0) at util.c:1561
#2  0x0000000100211833 in Perl_mess (my_perl=0x100803200, pat=0x10056d800 "free op at %p, recorded in slab %p") at util.c:1391
#3  0x000000010001bfbc in Perl_Slab_Free (my_perl=0x100803200, op=0x10070ffd8) at op.c:442
#4  0x000000010001cafe in Perl_op_free (my_perl=0x100803200, o=0x10070ffd8) at op.c:855
#5  0x000000010001c95e in Perl_op_free (my_perl=0x100803200, o=0x10080ebc0) at op.c:837
#6  0x00000001003a8c8e in Perl_leave_scope (my_perl=0x100803200, base=0) at scope.c:1109
...


-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=129027

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About