From duncf@debian.org

When profiling SpamAssassin's mass-check command, dprofpp generates
loads of errors​:

Net​::DNS​::Resolver​::Base​::AUTOLOAD has -8 unstacked calls in outer
File​::Glob​::GLOB_TILDE has 1 unstacked calls in outer
POSIX​::AUTOLOAD has -1 unstacked calls in outer
Exporter​::Heavy​::heavy_export has 23 unstacked calls in outer
Socket​::AUTOLOAD has -6 unstacked calls in outer
File​::Glob​::GLOB_BRACE has 1 unstacked calls in outer
File​::Glob​::GLOB_NOMAGIC has 1 unstacked calls in outer
File​::Glob​::AUTOLOAD has -5 unstacked calls in outer
File​::Glob​::GLOB_QUOTE has 1 unstacked calls in outer
Fcntl​::AUTOLOAD has -5 unstacked calls in outer
Socket​::__ANON__ has 6 unstacked calls in outer
POSIX​::load_imports has 1 unstacked calls in outer
Net​::DNS​::Resolver​::Base​::__ANON__ has 8 unstacked calls in outer
Fcntl​::__ANON__ has 5 unstacked calls in outer
File​::Glob​::GLOB_ALPHASORT has 1 unstacked calls in outer
Exporter​::export has -23 unstacked calls in outer

This seems to be a bug in Devel​::DProf, rather than a bug in
SpamAssassin. Is there a more up to date version of Devel​::DProf we
can try? (We've reproduced this on the version that comes with perl
5.6.8)

Steps to reproduce​:

- Download SpamAssassin from SVN or Version 3.0x
Trunk​: svn checkout https://svn.apache.org/repos/asf/spamassassin/trunk spamassassin-trunk

$ cd spamassassin/masses
$ perl -d​:DProf ./mass-check --file ../sample-spam.txt

mass-check runs spamassassin over sample-spam.txt and returns the rules hit

$ dprofpp -O1000 > /tmp/out
Net​::DNS​::Resolver​::Base​::AUTOLOAD has -4 unstacked calls in outer
Sys​::Syslog​::AUTOLOAD has -1 unstacked calls in outer
File​::Glob​::GLOB_TILDE has 1 unstacked calls in outer
POSIX​::AUTOLOAD has -1 unstacked calls in outer
Sys​::Syslog​::__ANON__ has 1 unstacked calls in outer
Exporter​::Heavy​::heavy_export has 22 unstacked calls in outer
Socket​::AUTOLOAD has -5 unstacked calls in outer
File​::Glob​::GLOB_BRACE has 1 unstacked calls in outer
File​::Glob​::GLOB_NOMAGIC has 1 unstacked calls in outer
File​::Glob​::AUTOLOAD has -5 unstacked calls in outer
File​::Glob​::GLOB_QUOTE has 1 unstacked calls in outer
Fcntl​::AUTOLOAD has -4 unstacked calls in outer
Socket​::__ANON__ has 5 unstacked calls in outer
POSIX​::load_imports has 1 unstacked calls in outer
Net​::DNS​::Resolver​::Base​::__ANON__ has 4 unstacked calls in outer
Fcntl​::__ANON__ has 4 unstacked calls in outer
File​::Glob​::GLOB_ALPHASORT has 1 unstacked calls in outer
Exporter​::export has -22 unstacked calls in outer

This behaviour has been found on Debian testing (perl 5.6.4), Debian
experimental (perl 5.6.8), FreeBSD (perl 5.6.4).

I can provide tmon.out if necessary.

The output of perlbug -d is below​:

Flags​:
  category=
  severity=

Site configuration information for perl v5.8.6​:

Configured by Debian Project at Sat May 21 21​:38​:05 EST 2005.

Summary of my perl5 (revision 5 version 8 subversion 6) configuration​:
  Platform​:
  osname=linux, osvers=2.4.27-ti1211, archname=i386-linux-thread-multi
  uname='linux kosh 2.4.27-ti1211 #1 sun sep 19 18​:17​:45 est 2004 i686 gnulinux '
  config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.6 -Dsitearch=/usr/local/lib/perl/5.8.6 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.6 -Dd_dosuid -des'
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=define use5005threads=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='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include'
  ccversion='', gccversion='3.3.6 (Debian 1​:3.3.6-5)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=4, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib
  libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
  perllibs=-ldl -lm -lpthread -lc -lcrypt
  libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.6
  gnulibc_version='2.3.2'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches​:
 

@​INC for perl v5.8.6​:
  /etc/perl
  /usr/local/lib/perl/5.8.6
  /usr/local/share/perl/5.8.6
  /usr/lib/perl5
  /usr/share/perl5
  /usr/lib/perl/5.8
  /usr/share/perl/5.8
  /usr/local/lib/site_perl
  /usr/local/lib/perl/5.8.4
  /usr/local/share/perl/5.8.4
  .

Environment for perl v5.8.6​:
  HOME=/home/duncf
  LANG=en_US
  LANGUAGE=en_US​:en_GB​:en
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/local/bin​:/usr/bin​:/bin​:/usr/bin/X11​:/usr/games
  PERL_BADLANG (unset)
  SHELL=/bin/bash

--
Duncan Findlay

From duncf@debian.org

I made a couple of rather critical typos in the original message.

It fails on 5.8.4 and 5.8.6, NOT 5.6.x (haven't tested 5.6.x).

Let me know if you need any further clarification.

Duncan

From duncf@debian.org

I believe I have found a patch for this issue.

I have attached the patch. This seems to fix the warnings and produce
no deviation from the original results.

--
Duncan Findlay

From duncf@debian.org

Index​: dprofpp

RCS file​: /cvsroot/ipas/Mail-SpamAssassin/tools/dprofpp,v
retrieving revision 1.1
diff -u -r1.1 dprofpp
--- dprofpp 7 Apr 2005 03​:35​:32 -0000 1.1
+++ dprofpp 1 Jun 2005 16​:14​:29 -0000
@​@​ -691,7 +691,7 @​@​
  $t - $overhead) if $opt_S;
  exitstamp( \@​stack, \@​tstack,
  $t - $overhead,
- $times, $ctimes, $ename, \$in, $tab,
+ $times, $ctimes, $name, \$in, $tab,
  $curdeep_times, \%outer );
  }
  next unless $in_level or $name eq $opt_g;

From @rgs

Duncan Findlay wrote​:

I believe I have found a patch for this issue.

I have attached the patch. This seems to fix the warnings and produce
no deviation from the original results.

I can't claim I understand dprofpp, but this patch looks minimally sane.
Thanks, applied as #24693.

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

@rgs - Status changed from 'open' to 'resolved'

From @steve-m-hay

Rafael Garcia-Suarez wrote​:

Duncan Findlay wrote​:

I believe I have found a patch for this issue.

I have attached the patch. This seems to fix the warnings and produce
no deviation from the original results.

I can't claim I understand dprofpp, but this patch looks minimally sane.

You're saying that the patch is as least sane as is possible! I think
"minimally insane" would be better ;-)

(Apologies for a moment of insanity on my part.)

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses​: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.