$mapfile = "test.map"; $map = ms_newMapObj($mapfile); // OR $map = new MapObj($mapfile); $pnt = ms_newPointObj(); $pnt->setXY(250,200);

[armin]

The MS 6-beta1 seems to have a problem in the function setXY() for point objects. The following code causes a segmentation fault (something like "child pid 16057 exit signal Segmentation fault (11)" in the Apache error log):

$pnt = new PointObj();
$pnt->setXY(250,200);

Same problem appears when creating the point with the old syntax

$pnt = ms_newPointObj();

The environment I used is Ubuntu 10.04, PHP 5.3.5 and Apache2 prefork (PHP as DSO).

[aboudreault]

Can't reproduce the bug. Tried with a simple php script and php-cli and the same script executed by apache. Are you sure you can reproduce the bug on another machine? It might be not related to mapserver.

[armin]

It seems to be especially in combination with other Mapscript requests. Some testing:

$pnt = new PointObj();
$pnt->setXY(250,200);

=> segmentation fault

$pnt = new PointObj();

=> no errors

$pnt = ms_newPointObj();
$pnt->setXY(250,200);

=> no errors

$mapfile = "test.map";
$map = ms_newMapObj($mapfile);
    // OR $map = new MapObj($mapfile);
$pnt = ms_newPointObj();
$pnt->setXY(250,200);

=> segmentation fault

All tests run with PHP CLI.

[aboudreault]

Still unable to reproduce it with mapserver trunk and php 5.3.5 using the CLI. :(

[armin]

I will see if I can try it on another computer with another OS.

Do you know if there is any possibility running a debugging tool for this? gdb does not seem to work with PHP calls.

Otherwise I hope someone else will stumble once over the same error...

Armin

[aboudreault]

I've never get gdb working properly with php. I suggest you to ask on the #php.pecl channel on irc.efnet.net network. Those people should know how.

[armin]

I uploaded the core dump opened with gdb. Strangely enough the error running the script via the command line did not appear when compiling Mapserver with --enable-debug. But then still other errors happened inside Apache call, see 2nd core dump.

For the time being I think I will give up trying MapServer/Mapscript 6 since it's too difficult to see where something fails in more complex applications, and very confusing under which circumstances. With PHP as Apache module I get segfaults and as CGI "premature end of script headers" (both work fine with Mapserver 5.4 and 5.6).

Appears to me the whole PHP Mapscript has been completely reworked, file structure looks quite different from 5.x versions.

[aboudreault]

armin, could you try the beta5 release to see if your problem persist.

[armin]

I checked the beta5 and still get the same segfault. See mapscript_segfaults_beta5.txt. The code used was:

$mapfile = "test.map";
$map = ms_newMapObj($mapfile);
$pnt = ms_newPointObj();
$pnt->setXY(250,200);

[aboudreault]

It seems that you are the only one with that bug :(.

[mgleahy]

I can produce this same problem, although it only happens with the use of setXY in code deeply embedded in my application. I can't reproduce the problem with a simple example like above, but it is very consistent in my application's code. So it does seem to have a dependency on some condition that I haven't been able to identify yet.

I can circumvent this by using $pnt->x=$x; $pnt->y=$y;

With PHP being handled by mod_php5 in apache, the error looks like:

[Mon Apr 25 16:33:01 2011] [notice] child pid 8679 exit signal Segmentation fault (11)

Using php-cgi through cgid:

[Mon Apr 25 17:05:54 2011] [error] [client 127.0.0.1] Premature end of script headers: php-cgi

Using php through mod_fcgid:

[Mon Apr 25 13:56:05 2011] [warn] [client 127.0.0.1] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server, referer: ​https://localhost/myapp/ [Mon Apr 25 13:56:05 2011] [error] [client 127.0.0.1] Premature end of script headers: index.php, referer: ​https://localhost/myapp/

[mgleahy]

Ok...I just duplicated this with the following:

<?php

$mapfile = "/path/to/my/mapfile.map";

$map = ms_newMapObj($mapfile);
$pnt = ms_newPointObj();

var_dump($pnt);

$pnt->setXY(250,200);

?>

The only thing that seems to have triggered this was the var_dump(), which as far as I understand should not have any impact on anything.

The actual output from running this via commandline looks like:

object(pointObj)#2 (0) {
}
Segmentation fault

I've attached output from valgrind. I'm not sure if that will help any.

[mgleahy]

Also interesting:

<?php

$pnt = ms_newPointObj();
echo (property_exists($pnt,"setXY")?"exists\n":"does not\n");
$pnt->setXY(250,200);

?>

outputs the following:

does not
Segmentation fault

I've also got slightly different valgrind output from this, also to be attached in a moment.

Let me know if there's more useful debugging I can do here.

[aboudreault]

• The var_dump() output is normal.. there is not registered properties directly in PHP since we are modifying the internal C object.
• The property_exists() result is correct. By using method_exists() with the setXY, it returns true.

After some code reading... I think I know where the problem is. I'm investigating in this.

[mgleahy]

I recognize the output is normal for both var_dump and property_exists. It's just that these were two examples I found through tinkering that consistently produced the segfault for me. In contrast, this does not produce a segfault:

<?php

$pnt = ms_newPointObj();
echo (method_exists($pnt,"setXY")?"exists\n":"does not\n");
$pnt->setXY(250,200);

?>

And the output is as expected (i.e., 'exists'). So it seems that certain interactions with mapscript and/or the point object itself are creating conditions that produce the segfault.

Thanks for looking into this - I'm definitely interested to see what you find.

[aboudreault]

Could you try to get a segfault using layer->getmetadata or layer->setmetadata ?

[mgleahy]

Ok, so this produces a segfault, after returning the 'text' string:

$pnt = ms_newPointObj();
$map = ms_newMapObj("/path/to/my/mapfile.map");
$layer = $map->getLayer(1);
$layer->setMetaData("test","text");
echo $layer->getMetaData("test")."\n";
$pnt->setXY(250,200);

This (which I tried first) does not produce a segfault:

$map = ms_newMapObj("/path/to/my/mapfile.map");
$layer = $map->getLayer(1);
$layer->setMetaData("test","text");
echo $layer->getMetaData("test")."\n";
$pnt = ms_newPointObj();
$pnt->setXY(250,200);

So the timing of the point object's creation seems to be important in this example. Although...in my application, the setXY method was being called immediately after the point object was created (although lots happens in my code prior to that point).

[aboudreault]

mgleahy, could you test the patch I've just attached?

[mgleahy]

No luck - after patching the file, compiling with either 6.0 beta 7 or svn trunk, I get this:

point.c: In function ‘zim_pointObj_setXY’:
point.c:198: error: request for member ‘m’ in something not a structure or union
make[1]: *** [point.o] Error 1
make[1]: Leaving directory `/scratch2/build/mapserversvn/mapserver/mapscript/php'

[mgleahy]

Oops...caught a typo in the patch. switched 'point.m' for 'point->m', and it works. The segfault does seem to be gone.

[aboudreault]

yes, replacing the . by -> do the trick. armin, could you also test and see if the patch fixes your issue? mgleahy, could you try your real application and confirm the patch also work?

[mgleahy]

Yep...it all looks good now as far as I am able to tell. I can no longer reproduce the error in any situation with this patch.

[aboudreault]

Ok, I think we got it, finally :). Committed and fixed in r11619. Could you guys test your application as soon as possible and confirm that the latest svn-trunk is ok? The release RC1 is planned for today.

[mgleahy]

I just tested r11619, and it also looks good.

Thanks very much.

[armin]

Hi everybody

I tried the latest beta7 with the patch from r11619 and everything works fine, both in a simple test script and in more complex application code. Thanks for sorting it out.

No I can try MS 6 and see what else has to be changed to get everything running in the various application modules I use. Looks like a small challenge to support both MS 6 and MS 5.x with the same code.