Debian Bug report logs - #477185
Memory leak in date command

[Message part 1 (text/plain, inline)]
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 see this on ps command, where the memory use goes up.

This arrive on AMD64 and i386 machines, in Etch, up to date.

Thanks
-- 
    __   __   ___  __
  /     /  /  /  /    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          ;-)

[smime.p7s (application/x-pkcs7-signature, attachment)]
On 21/04/2008, Dominique Fournier <dominique.fournier@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?

P.S. I can't reproduce the problem on lenny/sid.

>
>
>  I can see this on ps command, where the memory use goes up.
>
>  This arrive on AMD64 and i386 machines, in Etch, up to date.
>
>  Thanks
>  --
>     __   __   ___  __
>   /     /  /  /  /    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
>    ;-)
>
>
> _______________________________________________
>  pkg-php-maint mailing list
>  pkg-php-maint@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
>
>

-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

[Message part 1 (text/plain, inline)]
Raphael Geissert wrote:
> On 21/04/2008, Dominique Fournier <dominique.fournier@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          ;-)

[smime.p7s (application/x-pkcs7-signature, attachment)]
Version: 5.2.6.dfsg.1-1+lenny3

> P.S. I can't reproduce the problem on lenny/sid.

I'm closing the bug, since lenny is out.

-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/

Debian Bug report logs - #477185 Memory leak in date command

Debian Bug report logs - #477185
Memory leak in date command