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

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 )

--
Dan Collins

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

• [perl #129027] null pointer deref Perl_mess_sv (util.c:1508) by Father Chrysostomos via RT
• [perl #129027] null pointer deref Perl_mess_sv (util.c:1508) by Father Chrysostomos via RT
• [perl #129027] null pointer deref Perl_mess_sv (util.c:1508) by Dan Collins via RT