khael
khael

Reputation: 2610

PHP code generates a segmentation fault

Edit added.

I am getting a segmentation fault from the PHP ternary operation. I'm using PHP (5.4.13).

<?php

$t = empty($_GET['t2']) ? $_GET['t2'] : 'test';
$t = empty($_GET['t2']) ? 'test' : $_GET['t2'];

echo '<pre>'.print_r($t, true).'</pre>';

?>

The statements:

$t = empty($_GET['t2']) ? $_GET['t2'] : 'test';
$t = empty($_GET['t2']) ? 'test' : $_GET['t2'];

Dispatches a segmentation fault (I checked the apache error log for this). The commented statements above do not throw the segmentation fault.

I doubt this is the only source error, but this is what I was able to narrow down. Almost all sites that use this php are now having this problem.

I don't think this is a bug! More an error in php installation or in one of the dependencies. But as no function was used, only language features, I thought it could be narrowed down pretty easily.

EDIT: I wanted to know what are the common problems that causes a segmentation fault, and if one of them can be identified from the above code so that I will know where to look for solutions and how to act. (this is the question, for those who wonder about it)

EDIT 2: Ready now, there is no more assignment in $_GET, so I guess now it is advisable and valid. But the error is still there.

EDIT 3: for valgrind, the trace is:

==3775== Process terminating with default action of signal 11 (SIGSEGV)
==3775==  Bad permissions for mapped region at address 0x0
==3775==    at 0x0: ???
==3775==    by 0xF60F9F7: execute (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so)
==3775==    by 0xF5A619F: zend_execute_scripts (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so)
==3775==    by 0xF548E87: php_execute_script (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so)
==3775==    by 0xF650A94: ??? (in /opt/rh/php54/root/usr/lib64/httpd/modules/libphp5.so)
==3775==    by 0x133BAF: ap_run_handler (in /usr/sbin/httpd)
==3775==    by 0x13746D: ap_invoke_handler (in /usr/sbin/httpd)
==3775==    by 0x142B2F: ap_process_request (in /usr/sbin/httpd)
==3775==    by 0x13F9A7: ??? (in /usr/sbin/httpd)
==3775==    by 0x13B6B7: ap_run_process_connection (in /usr/sbin/httpd)
==3775==    by 0x147976: ??? (in /usr/sbin/httpd)
==3775==    by 0x147C45: ??? (in /usr/sbin/httpd)

and for gdb is:

#0  0x0000000000000000 in ?? ()
#1  0x00007fc4dd8a49f8 in execute () from /etc/httpd/modules/libphp54-php5.so
#2  0x00007fc4dd83b1a0 in zend_execute_scripts () from /etc/httpd/modules/libphp54-php5.so
#3  0x00007fc4dd7dde88 in php_execute_script () from /etc/httpd/modules/libphp54-php5.so
#4  0x00007fc4dd8e5a95 in ?? () from /etc/httpd/modules/libphp54-php5.so
#5  0x00007fc4e818dbb0 in ap_run_handler ()
#6  0x00007fc4e819146e in ap_invoke_handler ()
#7  0x00007fc4e819cb30 in ap_process_request ()
#8  0x00007fc4e81999a8 in ?? ()
#9  0x00007fc4e81956b8 in ap_run_process_connection ()
#10 0x00007fc4e81a1977 in ?? ()
#11 0x00007fc4e81a1c46 in ?? ()
#12 0x00007fc4e81a2293 in ap_mpm_run ()
#13 0x00007fc4e8179900 in main ()

Final Edit

As I suspected from the beginning it surely was from a corrupted installation of php and it's extensions. The code itself had no problem but I guess it used some part of the faulty installation. More can be added but as I did not found the exact cause and it's solution, but managing to make it work again, I thank you all for guiding me to a resolution.

Upvotes: 6

Views: 1437

Answers (1)

David Wallace
David Wallace

Reputation: 109

In looking at your code I don't believe you have any errors.

With that said you mentioned that you are now having issues with many of your sites. I am wondering if you are now getting hit by malicious bots that might be causing an error similar to what is on this [PHP Bug Report][1]https://bugs.php.net/bug.php?id=59748.[1]:.

I would look at your logs and see if traffic has changed on those sites to start taking advantage of this issue.

Upvotes: 1

Related Questions