Saving configuration on some modules causes Apache segmentation fault

Same here. In my case if I have any of image, upload, and/or urchin modules enabled, when I go to any other module's config and hit submit, I get a seg fault. The configuration options ARE saved, so the crash is happening somewhere in system_settings_form_submit after the variable_set statement. My bet is its happening in menu_rebuild();.

Reopening - it sho as **** aint working here. ;)

Marking as critical - this is crashing two different pure core sites, no additional modules. One of the two sites I haven't even enabled any modules beyond the default few when you first install Drupal and it's already doing it. This really needs to be fixed ASAP!

Add me to the list of people seeing this behavior.

Only by removing or disabling Image and Image_assist does it go away.

It affects more than just the settings for the Image-related modules, for example visiting Blog-API settings and pressing Save causes the Segmentation fault (11).

I spent HOURS putting debug statements into various includes and modules, but here is the problem: if you issue too much output via "echo" it seems to interfere with the page header() mechanisms and makes it hard to know if your debug statements are themselves causing problems. I believe that if I were to attempt it again, I would use ONLY drupal_set_message or watchdog calls to log messages. That is the way to go. Also, use flush() as needed to make sure output gets output!

The long and the short of it was that it did the save to database OK and it was doing the menu_rebuild but it never got back to index.php to do the switch() statement there.

forgot to say:

Drupal V 4.7.0 with latest Image, Img_assist as of May 9th download from drupal.org

Apache on Solaris

$ php -v
PHP 4.3.5 (cli) (built: Sep 10 2004 13:14:47)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Hi guys,

I notice from the only 2 operating systems listed here are "Unix" and Solaris. Could everyone else experiencing this state what OS they are using? I don't use Unix and I'm not really in any position to fix the image module though :)

I suspect (wild guess) the problem might be a bug in the PHP GD2 (or other) library when compiled on Solaris. It would explain why most people don't notice it when the majority would use Linux.

A bit more on my situation: first GD info, then Apache2 info, then PHP below:

$ ./gdlib-config --all
GD library  2.0.22
includedir: /usr/local/include
cflags:     -I/usr/local/include
ldflags:     -L/usr/local/lib  -L/usr/openwin/lib
libs:       -lXpm -lX11 -ljpeg -lfreetype -lpng12 -lz -lm 
libdir:     /usr/local/lib

Apache 2 info

$ ./fff/httpd-2.0.54/bin/httpd -V
Server version: Apache/2.0.54
Server built:   Jun 30 2005 15:23:25
Server's Module Magic Number: 20020903:9
Architecture:   32-bit
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_FCNTL_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/wwffw2/apache2/httpd-2.0.54"
 -D SUEXEC_BIN="/wwffw2/apache2/httpd-2.0.54/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
</code?

PHP

<code>
phpinfo()
PHP Version => 4.3.5

System => SunOS dmc 5.9 Generic_112233-08 sun4u
Build Date => Sep 10 2004 13:13:16
Configure Command =>  './configure' '--with-oci8=/usr/local/oracle_client/9.2' '--with-apache=/www/apache/apache_1.3.29' '--disable-cgi' '--with-gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local' '--with-ttf=/usr/local' '--with-tiff-dir=/usr/local' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' '--with-pdflib=/usr/local'

gd

GD Support => enabled
GD Version => 2.0 or higher
FreeType Support => enabled
FreeType Linkage => with freetype
JPG Support => enabled
PNG Support => enabled
WBMP Support => enabled

mysql

MySQL Support => enabled
Active Persistent Links => 0
Active Links => 0
Client API version => 3.23.49
MYSQL_MODULE_TYPE => builtin
MYSQL_SOCKET => /tmp/mysql.sock
MYSQL_INCLUDE =>  
MYSQL_LIBS =>  

Directive => Local Value => Master Value
mysql.allow_persistent => On => On
mysql.connect_timeout => 60 => 60
mysql.default_host => no value => no value
mysql.default_password => no value => no value
mysql.default_port => no value => no value
mysql.default_socket => no value => no value
mysql.default_user => no value => no value
mysql.max_links => Unlimited => Unlimited
mysql.max_persistent => Unlimited => Unlimited
mysql.trace_mode => Off => Off

A bit more on my situation: first GD info, then Apache2 info, then PHP below:

$ ./gdlib-config --all
GD library  2.0.22
includedir: /usr/local/include
cflags:     -I/usr/local/include
ldflags:     -L/usr/local/lib  -L/usr/openwin/lib
libs:       -lXpm -lX11 -ljpeg -lfreetype -lpng12 -lz -lm 
libdir:     /usr/local/lib

Apache 2 info

$ ./fff/httpd-2.0.54/bin/httpd -V
Server version: Apache/2.0.54
Server built:   Jun 30 2005 15:23:25
Server's Module Magic Number: 20020903:9
Architecture:   32-bit
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_FCNTL_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/wwffw2/apache2/httpd-2.0.54"
 -D SUEXEC_BIN="/wwffw2/apache2/httpd-2.0.54/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

PHP

phpinfo()
PHP Version => 4.3.5

System => SunOS dmc 5.9 Generic_112233-08 sun4u
Build Date => Sep 10 2004 13:13:16
Configure Command =>  './configure' '--with-oci8=/usr/local/oracle_client/9.2' '--with-apache=/www/apache/apache_1.3.29' '--disable-cgi' '--with-gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local' '--with-ttf=/usr/local' '--with-tiff-dir=/usr/local' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' '--with-pdflib=/usr/local'

gd

GD Support => enabled
GD Version => 2.0 or higher
FreeType Support => enabled
FreeType Linkage => with freetype
JPG Support => enabled
PNG Support => enabled
WBMP Support => enabled

mysql

MySQL Support => enabled
Active Persistent Links => 0
Active Links => 0
Client API version => 3.23.49
MYSQL_MODULE_TYPE => builtin
MYSQL_SOCKET => /tmp/mysql.sock
MYSQL_INCLUDE =>  
MYSQL_LIBS =>  

Directive => Local Value => Master Value
mysql.allow_persistent => On => On
mysql.connect_timeout => 60 => 60
mysql.default_host => no value => no value
mysql.default_password => no value => no value
mysql.default_port => no value => no value
mysql.default_socket => no value => no value
mysql.default_user => no value => no value
mysql.max_links => Unlimited => Unlimited
mysql.max_persistent => Unlimited => Unlimited
mysql.trace_mode => Off => Off

Sorry for duplicate post above. Can't delete it like I had hoped. (And when I hit Preview I don't see see a preview!)

Anyway this could be valuable.

When I had all the debug statements in my system.module, menu.inc etc etc. I had determined that the segmentation violation occurred after set_variable (and thus database save), after menu_rebuild completion, but before returning to index.php. This is as far as I got but here is the very end of my debug statements before core dumping

_menu_rebuild: done fetching objects.
_menu_rebuild: finding parents for big menu
_menu_rebuild: calling _menu_build_visible_tree ...
_menu_rebuild: finished.
menu_rebuild: back from _menu_build 
menu_rebuild: finished. 
system_settings_form_submit: finished 

Sorry for duplicate post above. Can't delete it like I had hoped. (And when I hit Preview I don't see see a preview!)

Anyway this could be valuable.

When I had all the debug statements in my system.module, menu.inc etc etc. I had determined that the segmentation violation occurred after set_variable (and thus database save), after menu_rebuild completion, but before returning to index.php. This is as far as I got but here is the very end of my debug statements before core dumping during a save (of Blog_API settings, not Image settings) :

_menu_rebuild: done fetching objects.
_menu_rebuild: finding parents for big menu
_menu_rebuild: calling _menu_build_visible_tree ...
_menu_rebuild: finished.
menu_rebuild: back from _menu_build 
menu_rebuild: finished. 
system_settings_form_submit: finished 

I've really no idea what this is about, but since various contrib modules are involved, I am inclined to mark it "won't fix". Probably a form APi issue in these modules.

also non-critical as many people apparently don't encoutner this problem.

Killes, as I said up-thread, it was happening on one site that was pure core - no additional modules whatsoever. It actually went away after I _added_ a module, of all things. The problem is definitely in that menu_rebuild function, at least on my server. It got all the way through that function, then died after it returned but before the calling function could execute any more code. I seem to recall chx saying it sounded like a corrupt stack problem.

To beat a dead horse. I have a multi-site install going and when I hit the create content > page link I get a segmentation fault. The other sites still work fine. The primary difference with this one and the others is that I set this one up rather quickly "enabled a lot of modules" all at once. Probably not the best practices method but I was in a hurry. So I will start over with a little rm -rf and do it slowly this time. More later...

Problem solved. Patience is a virtue. So far the rm -rf is working. For you widows folks thats deleting the directory (the cute little folder icon for the module). I guess I should not have rm -rf'd the directory (in the interest of science) however the interest of efficiency won out.

Lesson learned - set up your drupal slowly, one module at a time, followed by testing (spurious is ok).

Having similar issues with one of my installs. I can say that I probably enabled several modules at one time for this install. I tried removing my entire contrib folder, resaving the settings and modules pages, and then re-installing t he modules one-by-one. This didn't seem to do the trick as I am still having these issues. So far it is only admin pages (path_auto and video) where this is happening, so I will grin and bear it.

Additional note: We are running php4 on our dev environment. Recently we moved a site to a live environment that was running php5, and we have not seen the same issue there. I'll report back if I run into it there.

I have narrowed it down to this function. It has some documentation that seems to makes sense, but it could also be the problem. In drupal4.7 it is in the return of the module_implements function on line 145 of the includes/module.inc file.

here is the code for the function:

function module_implements($hook, $sort = FALSE) {
static $implementations;

if (!isset($implementations[$hook])) {
$implementations[$hook] = array();
$list = module_list(FALSE, TRUE, $sort);
foreach ($list as $module) {
if (module_hook($module, $hook)) {
$implementations[$hook][] = $module;
}
}
}

// The explicit cast forces a copy to be made. This is needed because
// $implementations[$hook] is only a reference to an element of
// $implementations and if there are nested foreaches (due to nested node
// API calls, for example), they would both manipulate the same array's
// references, which causes some modules' hooks not to be called.
// See also http://www.zend.com/zend/art/ref-count.php.
return (array)$implementations[$hook];
}

It seems to die on the return or the copy of the implements array. Beyond that I am still unaware of the cause.

I backed off some of my modules and it seems to have cleared up.

I faced the similar (or same?) problem when I was trying to install new modules. First, I tried to switch from PHP4 to PHP5. However, the problem still occured. Next, I increased "memory_limit" from 8M to 24M and everything goes fine now on PHP5.

There is an entry in Drupal FAQ for the problem related to the blank page:
http://drupal.org/node/31819

Based on a post from kpander (http://drupal.org/node/63181#comment-177728), I tried the following hack to menu.inc, and it seems to be working so far.

In _menu_sort(), he suggested changing this:

$a = &$menu['items'][$a];
$b = &$menu['items'][$b];

to this:

$a = $menu['items'][$a];
$b = $menu['items'][$b];

If someone who is a bit more familiar with menu.inc could take a look to let us know the possible consequences of this hack, that would be great.

Sean, can you include your OS, webserver name and version, and PHP version? Thanks!

Apache 2.0.46 (Red Hat) and PHP 4.3.11

http://drupal.org/node/109066 is also related, and the menu reference change in _menu_sort worked for me too.

And a patch and history for the menu.inc change: http://drupal.org/node/109074

I can't believe i'm having only seg'faults after just updating ANYTHING on the new drupal server who was bought for having more performance...

I applied the menu.inc patch, but no changes !

any news on this?

PS: yes - 4.7.6 here

We were just getting a bunch of segfaults on a PHP 4.6.5 install and upgraded to PHP 5.2.1 and it fixed it. Try recompiling PHP or switching versions. This is the month of PHP bugs after all! http://www.php-security.org

I meant 4.4.6 not 4.6.5.

I have been having the same problem under both Drupal 4.6.11 and 4.7.5, running under php4 and it seems to have gotten worse after a recent Debian php4 security update. I finally started comparing my configuration with that of another developer on this project who didn't appear to have problems and found he didn't have the Debian "php4-apd" package installed (profiler/debugger) so I commented out the following lines:

;zend_extension=/usr/lib/php4/20050606/apd.so ; php4-apd
;apd.dumpdir=/var/log/php4-apd ; php4-apd

in /etc/php4/apache/php.ini then stopped and started apache, and all the problems went away, uncomment the lines and they return, tried this several times.

Is anyone having the problem who doesn't have this installed and turned on?

Is anyone who has this turned on not having problems?
If so, are you running Debian or something else?

It would be good to know if this is a specific problem with the Debian build, or a generic problem with this extension, or if the problem is weirder and doing this fixes the problem for me but leaves others still broken

I have been having the same problem under both Drupal 4.6.11 and 4.7.5, running under php4 and it seems to have gotten worse after a recent Debian php4 security update. I finally started comparing my configuration with that of another developer on this project who didn't appear to have problems and found he didn't have the Debian "php4-apd" package installed (profiler/debugger) so I commented out the following lines:

;zend_extension=/usr/lib/php4/20050606/apd.so ; php4-apd
;apd.dumpdir=/var/log/php4-apd ; php4-apd

in /etc/php4/apache/php.ini then stopped and started apache, and all the problems went away, uncomment the lines and they return, tried this several times.

Is anyone having the problem who doesn't have this installed and turned on?

Is anyone who has this turned on not having problems?
If so, are you running Debian or something else?

It would be good to know if this is a specific problem with the Debian build, or a generic problem with this extension, or if the problem is weirder and doing this fixes the problem for me but leaves others still broken

@royrob : upgrade to PHP5.2.1 worked, but this PHP version killed the authentication on Drupal 4.7x sites on same server :-(

upgrade to PHP5.2.1 worked, but this PHP version killed the authentication on Drupal 4.7x sites on same server

That well known PHP 5.2 authentication issue was fixed in the 4.7.5 release. Authentication on PHP 5.2 seems to work fine since that fix.

http://drupal.org/node/93945

But seeing as you've already using Drupal 4.7.6 for security reasons, maybe it is really something else? ;)

This version is not supported. Reopen or create a new issue if the problem exists in any recent version (version equal or above Drupal 5)