Raphael Geissert wrote:
On 21/04/2008, Dominique Fournier <[EMAIL PROTECTED]> wrote:Package: php5-cli Version: 5.2.0-8+etch10Hello, 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
Description: S/MIME Cryptographic Signature
