valgrind errors in pp_seq dealing with semaphores #13626
Comments
From @khwilliamsonThese errors showed up t/io/sem ...................................................... And in cpan/IPC-SysV/t/sem ........................................... |
From @iabynOn Wed, Feb 26, 2014 at 08:36:36PM -0800, Karl Williamson wrote:
I can't reproduce these. Can you supply perl -V output? -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 02/28/2014 07:44 AM, Dave Mitchell wrote:
They are still there in today's blead run on dromedary, perl -V output We were talking on #irc about the advisability of doing regular smokes dromedary> myperl -V libpth=/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7 Characteristics of this binary (from libperl): |
From @khwilliamsonOn 02/28/2014 12:52 PM, Karl Williamson wrote:
I don't get a failure on my Ubuntu either, but they are still there on
|
From @tonycozOn Mon Mar 03 12:30:11 2014, public@khwilliamson.com wrote:
This appears to be a limitation in valgrind in that it doesn't treat that memory as initialized when semctl() returns, see: https://issues.apache.org/bugzilla/show_bug.cgi?id=53690 The following patch fixes the problem, but I'm not sure if it's worth applying: Inline Patchdiff --git a/doio.c b/doio.c
index bdff84c..6275aae 100644
--- a/doio.c
+++ b/doio.c
@@ -2117,6 +2117,7 @@ Perl_do_ipcctl(pTHX_ I32 optype, SV **mark, SV **sp)
{
SvPV_force_nolen(astr);
a = SvGROW(astr, infosize+1);
+ Zero(a, infosize, char);
}
else
{
Tony |
From @tonycozOn Tue Mar 04 21:16:17 2014, tonyc wrote:
The system valgrind is 3.8.1 so I installed 3.9.0, this displayed essentially the same errors: [tonyc@dromedary-001 perl]$ ~/local/valgrind-3.9.0/bin/valgrind ./perl t/io/sem.t
This continued to fix the error reports. Tony |
From @khwilliamsonOn 03/05/2014 07:46 PM, Tony Cook via RT wrote:
A reason some patch is worth applying is to keep this issue from coming |
From perl5-porters@perl.orgKarl Williamson wrote:
But this patch will cause a speed hit. Is it a good idea to have a |
From @tonycozOn Thu Mar 06 11:40:51 2014, perl5-porters@perl.org wrote:
Ideally this should be done with a suppression file, preferably one specific to t/io/sem.t (two of the warnings are pretty generic)
The problem is then we're valgrinding code that's different to what we send to users, which could hide a real problem (or produce a real change in behaviour). Reported to valgrind as https://bugs.kde.org/show_bug.cgi?id=331833 Tony |
From @khwilliamsonOn 03/06/2014 12:40 PM, Father Chrysostomos wrote:
Better than nothing is to add a comment at the place where a future |
From @tonycozOn Mon Mar 10 21:27:56 2014, public@khwilliamson.com wrote:
I thought about doing that, but the problem is the error backtraces point outside of where the problem is actually occurring. The only real solutions I see: 1) zero the memory before calling semctl() This may lead to a different false-negative for valgrind - if the semctl() fails, valgrind will treat the memory as initialized, even though it's not initialized usefully. 2) use test script specific suppressions They need to be script specific since, at least for this case the error is occurring in code that has nothing to do with semctl(), suppressing this call stack globally could lead to suppressing other unrelated errors. Tony |
Migrated from rt.perl.org#121335 (status was 'open')
Searchable as RT121335$
The text was updated successfully, but these errors were encountered: