Jump to:
| Project: | Acidfree Albums |
| Version: | 4.7.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Hello, I hope this is the correct place to place this issue. I've been trying and trying to get acidfree to work on my drupal 4.7 site, but have been having the following problem: I can create galleries, upload images, etc, but everytime I try to edit anything (move the images, change descriptions, etc.), I get dropped to a 500 Internal Server Error page. My system log reports "Premature end of script headers: /home/subwxnet/public_html/index.php", and as you might expect, non of the changes come through. I've tried just about everythign I can think of - checking directories, deleting and readding the database tables, uninstalling and reinstalling both acidfree and filemanager, etc. I've looked everywhere, and can find no way to make acidfree work.
Also, I just noticed that in the log I (sometimes, only sometimes) get this error: "Message array_walk() [function.array-walk]: Unable to call () - function does not exist in /home/subwxnet/public_html/includes/common.inc on line 509." I don't know if this is related.
According to cPanel, the server this site is hosting on is running PHP version 4.4.3 and MySQL version 4.1.20-standard.
Can anyone offer some assitance? I'm stumped. Thanks a lot!
Comments
#1
somebody else just reported 500 errors and said they saw them when trying to upload images larger than 1024. I told them to increase the max memory limit. Can you try this?
Can you check the webserver logs too? If webpages are ending in errors, the webserver should log the errors somewhere to help you diagnose them -- especially 5xx errors since that is the server error range.
#2
I am getting 500 errors also. This only occurs when I am in the album contents screen and try to do anything (move, copy delete, etc) to any of the listed photos. The apache error logs are as follows
[Wed Oct 18 12:13:11 2006] [error] Premature end of script headers: php-script, referer: http://testsite.org/node/20/contents
[error] [client xx.xx.xx] php-script: line 4: 404 Segmentation fault /usr/bin/php, referer: http://testsite.org/node/20/contents
#3
Well, that is a relief to me. It is not my code -- it is php that is segfaulting. I have actually seen this in other cases in writing drupal code -- but I can't remember where. Segfaults are a lot of fun to track down. Since this is happening on your server and not mine, you will have to do the footwork.
Since it seems to happen in the album contents section, one thing you might want to try is adding lines like this:
function acidfree_album_contents_submit($form_id, $form) {echo "got to line 667<br/>\n";
$node = $form['album'];
global $acidfree_types;
$parent = $form['parent'];
$targets = array();
foreach ($form['nodes'] as $fnode) {
echo "got to line 675<br/>\n";
$n = acidfree_get_node_by_id($fnode['nid']);
// troublesome keys -- they use an array on the form
// and then don't know how to handle it when it is passed back
$trouble_keys = array('path','og_nodeapi');
// this takes care of class extras and title
foreach ($fnode as $k => $v) {
if (is_array($v) && in_array(strtolower($k), $trouble_keys)) {
foreach ($v as $vk => $vv) {
$n->$vk = $vv;
}
} else
$n->$k = $v;
}
echo "got to line 689<br/>\n";
By inserting echo statements here and there, you might be able to track down what was last exectuted before the segfault. Then, when you narrow it down, you can delete old echo statements and add new ones closer to the issue. When you get it narrowed down to one line that prints, the next line executes and the print after that never happens, let me know the context of that line and which line it is and I will see what I can do.
#4
It seems as though the error occurs before the function is called because I commented out the entire block within the function and the error persists. Can you let me know the path of execution after the form is submitted so I can tried to pinpoint the source of the problem? btw. i'm using php v4.3.10
#5
On my system I put a backtrace call in and this is the path of functions that got me to the album contents submit function:
acidfree.module:667:acidfree_album_contents_submit(acidfree_album_contents,Array)
form.inc:200:call_user_func_array(acidfree_album_contents_submit,Array)
form.inc:127:drupal_submit_form(acidfree_album_contents,Array,)
acidfree.module:878:drupal_get_form(acidfree_album_contents,Array)
acidfree.module:1000:_acidfree_album_contents_form(Object)
acidfree.module:979:acidfree_page()
menu.inc:418:call_user_func_array(acidfree_page,Array)
index.php:15:menu_execute_active_handler()
drupal_get_form is what processes the form (builds, validates, submits and then renders). This gets called from _acidfree_album_contents_form because the form posts to the same path it came from. So you might try putting 'got to'/exit calls in along that path of functions and see what you come up with.
#6
I can't seem to get any messages to be outputted when the Internal Server Errors occur. Since echo statements get written out to the html response, I expected this to happen but I can't even get watchdog to write out debug messages either when the error occurs.
I'm not that proficient in php - is there any way to get some sort of logging to occur even when the 500 error happens?
#7
you could try putting in 'ob_flush();' after your echo lines. Sometimes that will let you force php to send output to the browser even if it is going to crash.
#8
I was having the same error described here with my site hosted on site5. Bunch of core files in the public_html folder. My config: Drupal 4.7.4, Acidfree (latest 4.7.x), Filemanager (latest 4.7.x)
When I changed my PHP to execute as PHP5 (5.2.0) rather than PHP4 (4.4.4) the problem dissapeared.
For my shared host I just add the following line to the .htaccess file
AddHandler application/x-httpd-php5 .php
For those unable to reproduce, are you running PHP5 or 4?
#9
Can it be that the module overloads the CPU of the hosting server and the process is then killed? I removed some of my 500 errors (those caused by Mass Import of Acidfree as well :), by enabling the throttle module. Hope it helps.
#10
I am closing this bug (along with all 4.7 bugs that are not security related). Try upgrading to drupal 5. Maybe things are better there. Acidfree is getting pretty close to a stable release, so spend your time testing it and send me some feedback.