serendipity_mb function segfault

[bobbitt]

Hi all,

I recently upgraded a longstanding installation to V1.7, and have discovered a problem. This is likely something specific to my configuration, but I am seeing very regular core dumps on my server, and have traced them back to serendipity's serendipity_mb function in include/lang.inc.php.

For those who are interested, here is the stack trace and debug:

Code: Select all

[root@server 70] systemd-private-sTKUBm >                  gdb httpd -c core.12408
GNU gdb (GDB) Fedora (7.4.50.20120120-54.fc17)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/httpd...Reading symbols from /usr/lib/debug/usr/sbin/httpd.debug...done.
done.
[New LWP 12408]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/httpd -k start'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f14e32832c8 in zend_hash_quick_find (ht=ht@entry=0x7f14efc189a8, arKey=0x7f14efdbf4e0 "mbstring", nKeyLength=9, h=h@entry=249897825911322699, pData=pData@entry=0x7fffaab901b8)
    at /usr/src/debug/php-5.4.15/Zend/zend_hash.c:950
950             p = ht->arBuckets[nIndex];
(gdb) bt
#0  0x00007f14e32832c8 in zend_hash_quick_find (ht=ht@entry=0x7f14efc189a8, arKey=0x7f14efdbf4e0 "mbstring", nKeyLength=9, h=h@entry=249897825911322699, pData=pData@entry=0x7fffaab901b8)
    at /usr/src/debug/php-5.4.15/Zend/zend_hash.c:950
#1  0x00007f14e32eed35 in zend_fetch_var_address_helper_SPEC_CONST_UNUSED (type=1, execute_data=<optimized out>, execute_data=<optimized out>)
    at /usr/src/debug/php-5.4.15/Zend/zend_vm_execute.h:5339
#2  0x00007f14e32d5ae7 in execute (op_array=0x7f14ef875000) at /usr/src/debug/php-5.4.15/Zend/zend_vm_execute.h:410
#3  0x00007f14e32760ec in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /usr/src/debug/php-5.4.15/Zend/zend.c:1315
#4  0x00007f14e321614d in php_execute_script (primary_file=primary_file@entry=0x7fffaab925c0) at /usr/src/debug/php-5.4.15/main/main.c:2492
#5  0x00007f14e331e28a in php_handler (r=0x7f14ef7807d0) at /usr/src/debug/php-5.4.15/sapi/apache2handler/sapi_apache2.c:667
#6  0x00007f14eeee2c40 in ap_run_handler (r=0x7f14ef7807d0) at /usr/src/debug/httpd-2.2.23/server/config.c:158
#7  0x00007f14eeee308b in ap_invoke_handler (r=r@entry=0x7f14ef7807d0) at /usr/src/debug/httpd-2.2.23/server/config.c:376
#8  0x00007f14eeef06b8 in ap_process_request (r=r@entry=0x7f14ef7807d0) at /usr/src/debug/httpd-2.2.23/modules/http/http_request.c:282
#9  0x00007f14eeeed578 in ap_process_http_connection (c=0x7f14ef7687a0) at /usr/src/debug/httpd-2.2.23/modules/http/http_core.c:190
#10 0x00007f14eeee9620 in ap_run_process_connection (c=0x7f14ef7687a0) at /usr/src/debug/httpd-2.2.23/server/connection.c:43
#11 0x00007f14eeee9a38 in ap_process_connection (c=c@entry=0x7f14ef7687a0, csd=<optimized out>) at /usr/src/debug/httpd-2.2.23/server/connection.c:190
#12 0x00007f14eeef5279 in child_main (child_num_arg=child_num_arg@entry=89) at /usr/src/debug/httpd-2.2.23/server/mpm/prefork/prefork.c:667
#13 0x00007f14eeef5992 in make_child (slot=89, s=0x7f14ef162880) at /usr/src/debug/httpd-2.2.23/server/mpm/prefork/prefork.c:768
#14 make_child (s=0x7f14ef162880, slot=89) at /usr/src/debug/httpd-2.2.23/server/mpm/prefork/prefork.c:696
#15 0x00007f14eeef64f6 in perform_idle_server_maintenance (p=<optimized out>) at /usr/src/debug/httpd-2.2.23/server/mpm/prefork/prefork.c:903
#16 ap_mpm_run (_pconf=_pconf@entry=0x7f14ef15d158, plog=<optimized out>, s=s@entry=0x7f14ef162880) at /usr/src/debug/httpd-2.2.23/server/mpm/prefork/prefork.c:1107
#17 0x00007f14eeecd887 in main (argc=3, argv=0x7fffaab92c28) at /usr/src/debug/httpd-2.2.23/server/main.c:753
(gdb) frame 3
#3  0x00007f14e32760ec in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /usr/src/debug/php-5.4.15/Zend/zend.c:1315
1315                            zend_execute(EG(active_op_array) TSRMLS_CC);
(gdb) print (char *)executor_globals.active_op_array->filename
$1 = 0x7f14ef7c9720 "/var/www/site/serendipity/include/lang.inc.php"
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x7f14efdbf190 "serendipity_mb"
(gdb)

Granted, this is a bug in zend/php but it seems to be triggered by serendipity, likely accessing an array element that doesn't exist. I have disabled my serendipity site for now, and should know for certain if this was the issue soon. Core dumps were happening every few minutes before... so far, all is quiet.

Not trying to point fingers, lay blame or even vent. Just trying to help out the team or anyone else who may be seeing similar problems.

P.S. System is Fedora 17, httpd-2.2.23-1.fc17.x86_64, php-5.4.15-1.fc17.x86_64.

[garvinhicking]

Hi!

Hm, that's interesting. Of course generally speaking I agree this is a Zend/PHP, and segfaulting should never happen, and never be triggered by a PHP execution - so while this definitely needs fixing in Zend/PHP, we would be happy to offer any hotfix to serendipity_mb.

The function is defined in include/lang.inc.php and I don't see anything really nasty. You could add some debugging to the function, like for each case you could add something like:

Code: Select all

$fp=fopen('/tmp/mbstring.log','a');
fwrite($fp, 'Trying ucfirst with parameters: ...');
fclose($fp);

// Actual action here, inside the switch($func) part

$fp=fopen('/tmp/mbstring.log','a');
fwrite($fp, 'Success!');
fclose($fp);

This would write a file with each success call; we would need to watch out for places where a mb call is made, but no return text was there.

You could also try to make a test case for each variant of serendipity_mb, like this:

Code: Select all

<?php // mbtest.php

include 'serendipity_config.inc.php'; // Init s9y framework

$calls = array('ucfirst', 'strtolower', 'strtoupper', 'substr'); // Setup all valid func calls
$vars = array('A test string', '', array(), null); // Setup all valid variables
$extra = array('substr' => array(0,2), array(1,2), array(-1,-1), array(0,-1), array(2,-1), array(null, -1)); // Extra parameters for substr

foreach($calls AS $call) {
   foreach($vars AS $var) {
       echo "Call: " . $call . " with var: ";
       var_dump($var);
       echo "\n";
       $result = serendipity_mb($call, $var);
       echo "RESULT: ";
       var_dump($result);

       if ($extra[$call]) {
           foreach($extra[$call] AS $extravars) {
               echo "Extra-Call " . $call . " with vars: ";
               var_dump($extravars);
               echo "\n";
               $result = serendipity_mb($call, $var, $extravars[0], $extravars[1]);
               echo "EXTRA-RESULT: ";
               var_dump($result);
           }
       }
    }
}
echo "All Done. Bye-Bye.\n";

Then call it in your browser (and maybe also via CLI) and check if it coredumps. This test should basically cover all variants that can happen in usual s9y style, let's see if we can pinpoint...

(You might want to upgrade your PHP, maybe on a test-vm or test-instance, or parallely to your current PHP and test it with that?)

Thanks for reporting!

Regards,
Garvin

[Timbalu]

Upps, didn't see Garvins answer....
upgrading php should be better downgrading in his case...

What do you mean by "I am seeing very regular core dumps on my server"?

Well, it seems you either dont have the 'mbstring' extension loaded or mb_internal_encoding can't be properly read.

Please change Line 72

Code: Select all

$mbstring = (extension_loaded('mbstring') && @mb_internal_encoding(LANG_CHARSET) ? 1 : 0);

to

Code: Select all

$mbstring = (@extension_loaded('mbstring') && @mb_internal_encoding(LANG_CHARSET) ? 1 : 0);

This zend debug trace thing is ugly and hardly readable... Would it help to see if Serendipity could produce its own?
Turn on

Code: Select all

$serendipity['production'] = 'debug';

in your serendipity_config_local.inc.php file.

[bobbitt]

Thanks guys. It seems that getting rid of the php-pecl-apc-3.1.15-0.3.svn329913.fc17.x86_64 and php-pear-1.9.4-7.fc17.2.noarch packages may have done the trick. I'll do some more testing to see if I can help find the source... It's looking more and more like I suspected, which is just a 'wonky' setup on my end.

I'll let you know what I find.


Cheers
Mike