[php-maint] Bug#477185: Bug#477185: Memory leak in date command

[Dominique Fournier]

Raphael Geissert wrote:
> On 21/04/2008, Dominique Fournier <dominique.fournier at grenoble.cnrs.fr> wrote:
>> Package: php5-cli
>>  Version: 5.2.0-8+etch10
>>
>>  Hello,
>>
>>  When I use the date command in a loop, I see the memory grow up.
>>  Code :
>>  <?
>>     while (1)
>>     {
>>       printf (date("d/m/Y H:i:s")." ".memory_get_usage() ." \n");
>>     }
>>  ?>
>>
>>
>>  The result is :
>>  ....
>>  21/04/2008 18:51:32 15657592
>>  21/04/2008 18:51:32 15658136
>>  21/04/2008 18:51:32 15658680
>>  21/04/2008 18:51:32 15659224
>>  21/04/2008 18:51:32 15659768
>>  21/04/2008 18:51:32 15660312
>>  ...
> 
> I can confirm in etch with php5 5.2.0-8+etch10 only under i686, but
> not under x86_64.
> 
> Related stuff:
> 
> On the machine where I can reproduce:
> $ apt-cache policy tzdata
> tzdata:
>   Installed: 2007k-1etch1
> Related stuff:
> 
> On the machine where I can NOT reproduce:
> $ apt-cache policy tzdata
> tzdata:
>   Installed: 2007j-1etch1
> 
> ... but even after upgrading to 2007k-1etch1, as expected, I still
> can't reproduce.
> 
> I guess valgrind is our friend in this case, anyone willing to track this down?

Valgrind result :

  # valgrind php test.php
==1694== Memcheck, a memory error detector.
==1694== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==1694== Using LibVEX rev 1658, a library for dynamic binary translation.
==1694== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==1694== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation 
framework.
==1694== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==1694== For more details, rerun with: -v
==1694==
vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
==1694== valgrind: Unrecognised instruction at address 0x4016701.
==1694== Your program just tried to execute an instruction that Valgrind
==1694== did not recognise.  There are two possible reasons for this.
==1694== 1. Your program has a bug and erroneously jumped to a non-code
==1694==    location.  If you are running Memcheck and you just saw a
==1694==    warning about a bad jump, it's probably your program's fault.
==1694== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1694==    i.e. it's Valgrind's fault.  If you think this is the case or
==1694==    you are not sure, please let us know and we'll try to fix it.
==1694== Either way, Valgrind will now raise a SIGILL signal which will
==1694== probably kill your program.
==1694==
==1694== Process terminating with default action of signal 4 (SIGILL)
==1694==  Illegal opcode at address 0x4016701
==1694==    at 0x4016701: (within /lib/ld-2.7.so)
==1694==    by 0x4007D42: (within /lib/ld-2.7.so)
==1694==    by 0x4003339: (within /lib/ld-2.7.so)
==1694==    by 0x4014837: (within /lib/ld-2.7.so)
==1694==    by 0x400230A: (within /lib/ld-2.7.so)
==1694==    by 0x4000A67: (within /lib/ld-2.7.so)
==1694==
==1694== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==1694== malloc/free: in use at exit: 0 bytes in 0 blocks.
==1694== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==1694== For counts of detected errors, rerun with: -v
==1694== All heap blocks were freed -- no leaks are possible.
Illegal instruction

My problem is on AMD64,

apt-cache policy tzdata
tzdata:
   Installed: 2007j-1etch1
   Candidate: 2007j-1etch1

-- 
     __   __   ___  __
   /     /  /  /  /    Dominique Fournier
  /     /__/  /  /     CNRS / Centre Réseau et Informatique Commun
  \___ /  \ _/_  \___  Tel : 04 76 88 78 59 / Fax : 04 76 88 12 95
                       Assistance Technique  CRIC : 04 76 88 79 54
Certificats :  http://igc.services.cnrs.fr/Doc/General/trust.html
Site Perso  :  http://dominique.fournier.homedns.org          ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4093 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20080422/c3a3bae9/attachment.bin