selectOutputFormat does not update correclt the php pointer to the current outputformat set in the map file

[assefa]

Here is a scenario:

mapfile contains an imagetype and one outputformat

  IMAGETYPE png

  ...
  OUTPUTFORMAT
    NAME "mypdf"
    ...
  END  

php script

$map_file="f:/msapps/gmap_pdf/htdocs/gmap75.map";
$oMap = ms_newMapObj("$map_file");
$oMap->selectOutputFormat("mypdf");
$oMap->outputformat->setOption("aaa", 30);

This has the effect of modifying the "wrong" outputformat (in this case the outputformat defined as "png") instead of modifying the "mypdf" format.

[assefa]

The issue I think is that the php object still points to the original outputformat instead of the new outputformat set in the map.

Not sure what the best approach is to solve this but one way could be to add a map_handle in the object and use it to always select the current output object.

[dmorissette]

The _map_handle_ approach could possibly work, but the handle of the PHP object at map->outputformat would be invalid (since it would still refer to the original outputFormatObj C struct).

Perhaps a cleaner fix would be to destroy the map->outputformat PHP object (which is a PHP wrapper with a ref to the C struct with a stub destructor that does nothing) and create a new one in php3_ms_map_selectOutputFormat() using _phpms_build_outputformat_object()? I don't think we do that kind of stuff anywhere yet, but this way the handle would be maintained properly.

[assefa]

patch for php_mapscript.c

[assefa]

Attaching is the patch I want to apply. I am not sure if this is good enough (not losing memory) but solves the initial issue described in this bug.

[assefa]

committed patch (r7613)

[dmorissette]

FYI I tested r7613 under Valgrind with a PHP script that changes the outputFormatObj multiple times and uses print_r to dump it and no leak or memory errors were reported, and according to print_r the object is updated properly every time.

There might still be leaks that are caught by the PHP garbage collector before Valgrind sees them, but at least I can confirm that there are no persistent leaks or corruption of underlying MapServer C structs.

[assefa]

Thanks for doing the tests.