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
fuzzing testcase triggers LeakSanitizer over 101 byte memory leak #15752
Comments
From @geeknikTriggered with Perl v5.25.7-26-g7332835. I've never seen this before with ./perl test269 ================================================================= Direct leak of 48 byte(s) in 1 object(s) allocated from: Direct leak of 38 byte(s) in 1 object(s) allocated from: Indirect leak of 15 byte(s) in 1 object(s) allocated from: SUMMARY: AddressSanitizer: 101 byte(s) leaked in 3 allocation(s). |
From @geeknik |
From @tonycozOn Mon, 05 Dec 2016 10:52:13 -0800, brian.carpenter@gmail.com wrote:
This looks like more than one bug, with some interactions between them. If I build blead with -DDEBUGGING -Doptimize=-O0\ -g and run your tony@mars:.../git/perl$ PERL_DESTRUCT_LEVEL=2 valgrind --leak-check=full ./perl ../130270.pl Note the panic, which probably causes the still reachable leaks. Sometimes the same invocation displays no "definitely lost": tony@mars:.../git/perl$ PERL_DESTRUCT_LEVEL=2 valgrind --leak-check=full ./perl ../130270.pl but we still have a panic. If I change the name of the test script (which I'd done to work on tony@mars:.../git/perl$ PERL_DESTRUCT_LEVEL=2 valgrind --leak-check=full ./perl ../130270b.pl I tried the following local change to track down the location more accurately: Inline Patchdiff --git a/sv.c b/sv.c
index dc392f0..95b0dad 100644
--- a/sv.c
+++ b/sv.c
@@ -348,6 +348,7 @@ S_new_SV(pTHX_ const char *file, int line, const char *func)
# define new_SV(p) (p)=S_new_SV(aTHX_ __FILE__, __LINE__, FUNCTION__)
#else
+#if 0
# define new_SV(p) \
STMT_START { \
if (PL_sv_root) \
@@ -360,6 +361,22 @@ S_new_SV(pTHX_ const char *file, int line, const char *func)
MEM_LOG_NEW_SV(p, __FILE__, __LINE__, FUNCTION__); \
} STMT_END
#endif
+# define new_SV(p) \
+ ((p) = S_new_SV(aTHX))
+
+static __inline__
+SV * S_new_SV(aTHX) {
+ SV *p;
+ if (PL_sv_root)
+ uproot_SV(p);
+ else
+ (p) = S_more_sv(aTHX);
+ SvANY(p) = 0;
+ SvREFCNT(p) = 1;
+ SvFLAGS(p) = 0;
+ return p;
+}
+#endif
/* del_SV(): return an empty SV head to the free list */
which is the call to uproot_SV(). Without valgrind this doesn't always segfault: tony@mars:.../git/perl$ PERL_DESTRUCT_LEVEL=2 ./perl ../130270b.pl but usually does: tony@mars:.../git/perl$ PERL_DESTRUCT_LEVEL=2 ./perl ../130270b.pl Tony |
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Mon, 05 Dec 2016 16:27:55 -0800, tonyc wrote:
Looking at this now: $ ./perl -Ilib -MO=Deparse ../130270.pl it looks like another stack-not-refcounted bug. Tony |
Migrated from rt.perl.org#130270 (status was 'open')
Searchable as RT130270$
The text was updated successfully, but these errors were encountered: