0006666: SIGSEGV in pcre_config - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0006666	mantisbt	other	public	2006-02-03 14:12	2008-04-19 04:10

Reporter	DGtlRift	Assigned To	grangeway
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	0.19.0rc1
Fixed in Version	1.2.0a1

Summary	0006666: SIGSEGV in pcre_config
Description	This is (IMHO) really a php or a perl compatible regex library issue, but I thought I would bring it up here first in order to figure out which one it is.
Additional Information	In our Mantis setup, we are using Subversion post-commit script to add comments to an issue. Every thing seems to work right and we have a number of tickets with subversion notes added after a commit. After a svn ci with a large number of changes (lot's of file modifications) the transaction worked without issue. However, when trying to view the specific issue ticket, the page stops just before rendering the notes (sometimes - but I think how far this gets is due to network traffic.) I tried it on 4 different webservers with the same mysql backend in this configuration: Solaris sparc Apache/1.3.22 Solaris sparc Apache/1.3.33 Solaris sparc Apache/2.0.55 (Unix) PHP/5.0.5 SVN/1.2.0 DAV/2 Fedora i686(SMP) Apache/2.0.54 (Fedora) All crashed with a SIGSEGV in the same area of download. The three Solaris boxes are off limits to me as root, but I was able to do some rudementary debugging on the linux box. For whatever reason I couldn't get Apache to create a core file, but I was able to attach the strace and gdb to watch what was happening... strace seemed to show that php had no problem getting the note data from the mysql server but then something happens after that causes a SIGSEGV gdb showed the backtrace after the crash that if went through the usual zend stuff and then: #0 0x00e44094 in pcre_config () from /lib/libpcre.so.0 0000001 0x00e4886a in pcre_config () from /lib/libpcre.so.0 0000002 0x00e47716 in pcre_config () from /lib/libpcre.so.0 0000003 0x00e47d7d in pcre_config () from /lib/libpcre.so.0 0000004 0x00e47716 in pcre_config () from /lib/libpcre.so.0 ... #19117 0x00e47d7d in pcre_config () from /lib/libpcre.so.0 #19118 0x00e47716 in pcre_config () from /lib/libpcre.so.0 #19119 0x00e48eb2 in pcre_config () from /lib/libpcre.so.0 #19120 0x00e4419c in pcre_config () from /lib/libpcre.so.0 #19121 0x00e49f57 in pcre_exec () from /lib/libpcre.so.0 #19122 0x0102e4dc in zif_preg_replace () from /etc/httpd/modules/libphp5.so #19123 0x0112bad8 in zend_do_fcall_common_helper () from /etc/httpd/modules/libphp5.so ... Zend stuff and what not at the bottom of the stack It seems to cycle back and forth in some recursion procedure in pcre_config at 0x00e47716 and 0x00e47d7d but there are no debug symbols in the library so other then disasembling the library, I'm not sure what's going. The fundamental question is whether this is an issue with the library (/lib/libpcre.so.0) or php? Once I have that answer I can persue it in those directions. The other question is if anyone else has seen a similar issue either in mantis or another php application, and what the workaround was for those applications and if mantis can do the same. I would include the bugnote that it is faulting on, but it contains propriatary information. Should also note that phpMyAdmin has no issue reading the bug note table and all of its contents. This issue is evil... just look at the number.
Tags	No tags attached.

grangeway 2007-07-24 12:56 reporter ~0015209	DGtlRift, Do you still have this issue with php? Paul

DGtlRift 2007-07-24 13:08 reporter ~0015210 Last edited: 2007-07-24 13:11	Yes... and just a little more detail - this shows up in the error.log: [Tue Jul 24 13:04:21 2007] [notice] child pid 8182 exit signal Segmentation fault (11) This is also on a new server (Sun) using the latest blastwave packages for php and apache.

grangeway 2007-07-24 14:45 reporter ~0015211	cool, so erm php version, and do you have the output from gdb of a "bt full" or whatever it is that shows variables etc, or any idea what causes the crash? Paul

DGtlRift 2007-07-24 19:15 reporter ~0015213	Blastwave package of PHP 5.2.1 Unfortunately... I do not have any more useful debug symbols... php gives me the symbols but the pcre library was apparently stripped of useful symbols. I can try to replicate the problem on my own system with a junk checkin... I have a hunch that since it seems to be a symptom of large change sets, the massive string representing the note is being passed recursively through the pcre code in php until php runs out of stack space where-ever pcre is being called.

grangeway 2007-07-27 16:12 reporter ~0015245	DGTlRift, Can you still reproduce this issue with the latest string_api.php from CVS? Paul

DGtlRift 2007-08-02 09:49 reporter ~0015330	Using $Id: string_api.php,v 1.91 2007/07/27 17:58:09 prichards Exp $ I am still unable to view the notes and get the same core file and seg fault.

grangeway 2007-12-08 19:41 reporter ~0016405	Hello, I believe that this is fixed by the commit at http://mantisbt.svn.sourceforge.net/viewvc/mantisbt/trunk/mantisbt/core/string_api.php?r1=4806&r2=4819 The fix will be in 1.2.X releases and also backported to 1.1 Thanks Paul

DGtlRift 2008-01-03 12:44 reporter ~0016542	I tried the latest svn head against a replica of our mantis backend and our regular installation (Mantis 1.1.0a3) The issue exists in 1.1.0a3 and is resolved in svn version 4854. I "updated" head string_api.php to version 4806 and the problem comes back. It would seem that this change set for string_api.php@4819 (which is reflected in the log entry) resolves this issue.