Compile PHP with --enable-debug to see if there are some leaks related.

Okay, I recompiled with --enable-debug. I also set "error_reporting  =  E_ALL" and "display_startup_errors = On" in the ini file. Nothing strange is reported during startup and the VSZ is still on average 140172 with resident at 5016.

Did Bug report 5571 provide any incite?

One other thing -- I am compiling with gcc version 3.2.2.

The patch from #5571 has been in PHP 4 since that bug was fixed..so it's not that.

Did you compile PHP 4.3.1 with GCC 3.2.2 ?
Did you have the same libmm for both?
Try this configure:

# rm config.cache && ./configure --disable-all --with-apxs=/usr/local/apache/bin/apxs --enable-session --with-mm=/usr/local

What is your session.save_handler ini option set to?

> 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.

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")

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.

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.

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?

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.