ID: 23905 Updated by: [EMAIL PROTECTED] Reported By: dsorrells at rhyton dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: FreeBSD 4.7 PHP Version: 4.3.2 New Comment:
Yes, it's very much possible it didn't get build, there were some bugs in there which were fixed for 4.3.2, iirc. And like I said before, I think it is perfectly normal that the VSZ grows quite big as when PHP loads, it initializes the mm module and does this: data->mm = mm_create(0, path); >From the mm man page: "A size of 0 means to allocate the maximum allowed size which is platform dependent and is between a few KB and the soft limit of 64MB." And the VSZ contains this shared memory segment size too.. So I don't think there are any bugs here. Previous Comments: ------------------------------------------------------------------------ [2003-06-06 10:30:28] dsorrells at rhyton dot com I just recompiled with the latest and greatest gcc v3.3, tried using gmake instead of make -- same results 139MB VSZ. Is it possible that some how mm didn't get compiled into our 4.3.1, even though it was listed in the config line? If so, is 139MB VSZ a normal build for PHP with mm? ------------------------------------------------------------------------ [2003-06-06 09:48:29] dsorrells at rhyton dot com Okay, this is strange. In the new bloated version, the phpinfo() page shows the following for sessions: Session Support enabled Registered save handlers files user mm In the non-bloated version, the phpinfo() page shows the following for sessions: Session Support enabled Registered save handlers files user Both have identical configuration options. You can feel free to look: Bloated: http://dev1.dnsrx.net/phptest.php Normal: http://www.winclients.com/phptest.php Now, here are objdumps for both libphp4.so files grep'n for mm: dev1.dnsrx.net: dev1 {12} % objdump -x libphp4.so | grep mm NEEDED libmm.so.13 21 .comment 00000ad4 00000000 00000000 0013e300 2**0 00000000 l d .comment 00000000 0002b638 l F .text 00000000 frame_dummy 0003864c l F .text 0000051d php_imagettftext_common 00000000 l df *ABS* 00000000 mod_mm.c 0006f3d8 l F .text 000001b5 php_make_safe_mode_command 0008d0b8 l F .text 0000012c php_spn_common_handler 000b3f20 l F .text 00000084 reportComment 000b72e4 l F .text 00000025 common 000b7520 l F .text 000001aa normal_scanComment 000bb474 l F .text 000001a0 little2_scanComment 000bf084 l F .text 000001a1 big2_scanComment 00000000 F *UND* 00000000 memmove 00000000 F *UND* 00000040 mmap 0011265e g O .rodata 00000004 php_sig_tif_mm 0006c140 g F .text 0000002b zif_gmmktime 0013d620 g O .data 00000078 php_commands 00034800 g F .text 000002b0 zif_imagegammacorrect 00000000 *UND* 00000000 ap_add_common_vars 000afbf4 g F .text 0000000e php_XML_SetCommentHandler winclients.com: winclients {36} % objdump -x libphp4.so | grep mm NEEDED libmm.so.13 21 .comment 00000ad4 00000000 00000000 0013e300 2**0 00000000 l d .comment 00000000 0002b638 l F .text 00000000 frame_dummy 0003864c l F .text 0000051d php_imagettftext_common 00000000 l df *ABS* 00000000 mod_mm.c 0006f3d8 l F .text 000001b5 php_make_safe_mode_command 0008d0b8 l F .text 0000012c php_spn_common_handler 000b3f20 l F .text 00000084 reportComment 000b72e4 l F .text 00000025 common 000b7520 l F .text 000001aa normal_scanComment 000bb474 l F .text 000001a0 little2_scanComment 000bf084 l F .text 000001a1 big2_scanComment 00000000 F *UND* 00000000 memmove 00000000 F *UND* 00000040 mmap 0011265e g O .rodata 00000004 php_sig_tif_mm 0006c140 g F .text 0000002b zif_gmmktime 0013d620 g O .data 00000078 php_commands 00034800 g F .text 000002b0 zif_imagegammacorrect 00000000 *UND* 00000000 ap_add_common_vars 000afbf4 g F .text 0000000e php_XML_SetCommentHandler Let me know what you think. Sorry that this has gotten so complicated. ------------------------------------------------------------------------ [2003-06-06 09:02:33] [EMAIL PROTECTED] And are you absolutely SURE the 4.3.1 had mm compiled into it? And it does seem quite normal to me, libmm allocates some initial memory block during the PHP startup. ------------------------------------------------------------------------ [2003-06-06 08:21:03] [EMAIL PROTECTED] What else changed between compiling PHP 4.3.1 and 4.3.2 ? Was the original 4.3.1 compiled with exactly same tools?? (the one that wasn't "bloated") ------------------------------------------------------------------------ [2003-06-06 06:35:09] dsorrells at rhyton dot com > Did you compile PHP 4.3.1 with GCC 3.2.2 ? Yes, but I tried a recompile of 4.3.1 again and it now gives a bloated VSZ too. (I give up!). > Did you have the same libmm for both? Yes. mm-1.3.0. > Try this configure: ..... Compiled using your suggested config and got similar bloat results on VSZ. > What is your session.save_handler ini option set to? The default "session.save_handler = files". I tar'd the whole src package and rebuilt on another machine and got the exact same results (bloat). It is definately tied to the inclusion of mm, as the VSZ goes to normal if mm is excluded. It would not be so bad if this had not built with no memory problems originally. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/23905 -- Edit this bug report at http://bugs.php.net/?id=23905&edit=1
