[SOLVED] HTTP POST failed: HTTP 500 Internal Server Error

jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Fri, 2012-07-06 08:18

This item was discussed in the locked thread http://gallery.menalto.com/node/101913. I would like to raise the topic again.

After upgrade to Debian Squeeze on my web server, the uploadapplet malfunctions. After upgrade and patch of both gallery remote - including applets - and uploadapplet applets, the uploadapplet at least executes. But after successful upload of one or two, I get the error message in the subject. The corresponding error messages in the apache2 error.log are

[Fri Jul 06 10:56:40 2012] [error] [client 10.0.12.118] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /usr/share/gallery2/modules/exif/lib/exifer/makers/olympus.inc on line 81
[Fri Jul 06 10:57:13 2012] [error] [client 10.0.12.118] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /usr/share/gallery2/modules/exif/lib/exifer/exif.inc on line 146

Also, please see http://gallery.menalto.com/node/107295, where this error first was posted.

/jason

EDIT: Fault in php.ini skipped logging. Fixed that, and now I have results.

 
suprsidr
suprsidr's picture

Joined: 2005-04-17
Posts: 8339
Posted: Fri, 2012-07-06 13:37
Quote:
[Fri Jul 06 10:56:40 2012] [error] [client 10.0.12.118] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /usr/share/gallery2/modules/exif/lib/exifer/makers/olympus.inc on line 81
[Fri Jul 06 10:57:13 2012] [error] [client 10.0.12.118] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /usr/share/gallery2/modules/exif/lib/exifer/exif.inc on line 146

try disabling the exif module and try again.

-s

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Fri, 2012-07-06 18:28
suprsidr wrote:
try disabling the exif module and try again.

Without the EXIF module both Uploadify and uploadapplet performs OK. But without the EXIF module I get the upload date as capture date, not the actual capture date :-(

Do you know of a update/patch of the EXIF module?

/jason

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Fri, 2012-07-06 21:48

It still seems it is your server setup that is the issue.

"...modules/exif/lib/exifer/makers/olympus.inc on line 81" from your error log refers to "$data=hexdec($data);"

"hexdec" is an internal PHP function but it is hanging your installation (Maximum execution time of 30 seconds exceeded).

Since it seems all these issues started since your OS upgrade and bearing in mind that you had a bad php.ini setup before, I'll say you should look into your OS upgrade again and perhaps hire someone to do it for you.

In any case, you should post any other similar issues you may have to a forum dealing with servers and server setups ... maybe Debian's support forum since your issues are related to your server setup.

A good question to ask the Debian people is why hexdec causes PHP to hang since you upgraded. They should be able to take things forward from there.

Good luck!

--
dakanji.com

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Sat, 2012-07-07 06:04

Thanks supssidr and Dayo for valuable comments. Since the only application that malfunctioned after the upgrade was/is Gallery upload it was the natural starting point of the debug process.

/jason

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Sat, 2012-07-07 06:34

That's logical.

Having done that, everything so far seems to point to problems with the OS upgrade.

All the best with fixing it and don't forget to come back to post the answer when you get it.

You might want to supply the server/debian folks the error messages and the specified files from the Exif module to help them along.

--
dakanji.com

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Sun, 2012-09-09 15:29

Re-activating this thread. Have contacted debian support. No answer as of yet.

In the meantime I have found that disabling all datafields in the EXIF/IPTC administration form doesn't change things; The same error still exits. I have also found that by totally deactivating the EXIF/IPTC module not only does upload of photos work, but also is the displaying of already stored/uploaded photos much faster. Is the EXIF/IPTC module used also when photos are displayed?

I have also found that I on my server have two different catalogs for Gallery2: /usr/share/gallery2 and /usr/share/gallery2.new. The latter is the older according to date and time stamps. Is this in any way negative for the performance of the EXIF/IPTC module or the whole application?

/jason

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Sun, 2012-09-09 17:31
Dayo wrote:
"...modules/exif/lib/exifer/makers/olympus.inc on line 81" from your error log refers to "$data=hexdec($data);"

I humbly dispute.

Debugging the module olympus.inc - I use an Olympus camera - it can be shown that whenever I display a photo the function formatOlympusData is called repeteadly until the execution timelimit is hit. And, when I upload photos, the number of times formatOlympusData is called from the function parseOlympus - that is the content of the variable $num - is 4949(!) and thus the function formatOlympusData is called accordingly ...

formatOlympusData must be called from different modules, but anyway too many times. There can't be 4949 tags, 49 tags seams more like it.

Hope this can help you help me.

/jason

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Mon, 2012-09-10 04:07
jason@barbanet wrote:
Re-activating this thread. Have contacted debian support. No answer as of yet.

We will get to this one later

Quote:
Is the EXIF/IPTC module used also when photos are displayed?

Yes it is

Quote:
I have also found that I on my server have two different catalogs for Gallery2: /usr/share/gallery2 and /usr/share/gallery2.new. The latter is the older according to date and time stamps. Is this in any way negative for the performance of the EXIF/IPTC module or the whole application?
/jason

The big clue here is the location "/usr/share/".
This tells me you have installed your Gallery using your distro's (Debian) package installer. This has been found in many cases to be associated with problems as it would appear that the packagers often add tweaks/hacks to the application to make it run out of deep server locations such as "/usr/share/" WHICH IT IS NOT DESIGNED TO RUN FROM.

This is all when and good when the application is being actively maintained by the packager but once it is not and the distro starts getting updated without corresponding updates to the added tweaks/hacks, things start to fall apart. Add that to having multiple installations on top of each other and you can see the potential for problems.

G2 is a web application for which the recommended installation procedure is simple. Download the files from the link in the top right corner of every page on this site, copy to the document root of your site, navigate to the site in your browser and follow the simple instructions. It is tried and tested over hundreds of thousands of installations. Needs no tweaks and/or hacks.

Now, I don't know what exactly ails your installation but once it turns out that you have used a package installer to install it, all bets are off and you will need to wait for Debian support to get back to you.

--
dakanji.com

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Mon, 2012-09-10 05:28
Dayo wrote:
Now, I don't know what exactly ails your installation but once it turns out that you have used a package installer to install it, all bets are off and you will need to wait for Debian support to get back to you.

OK.

I would be most grateful to know what module calls the function formatOlympusData in olympus.inc when displaying photos. I also would like to know if uninstalling the debian package and installing Gallery2 with the installer in any way affects the database.

/jason

 
suprsidr
suprsidr's picture

Joined: 2005-04-17
Posts: 8339
Posted: Mon, 2012-09-10 12:29

@jason, did you share a phpinfo link w/ us somewhere?

does your php have exif support?

-s
All New jQuery Minislideshow for G2/G3

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Mon, 2012-09-10 17:55
suprsidr wrote:
@jason, did you share a phpinfo link w/ us somewhere?

Not in this thread.

http://barbafarfar.barbanet.com/gallery/phpinfo.php

Quote:
does your php have exif support?

How do I find out? My php installation came along with Debian Squeeze as a package.

/jason

EDIT: changed URL to phpinfo

 
suprsidr
suprsidr's picture

Joined: 2005-04-17
Posts: 8339
Posted: Mon, 2012-09-10 17:41

FAQ: What information is required when I ask for help in the forums?
please remove the link to your php.ini and replace it w/ a link to your phpinfo as described in the above FAQ

-s
All New jQuery Minislideshow for G2/G3

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Mon, 2012-09-10 17:56
suprsidr wrote:
please remove the link to your php.ini and replace it w/ a link to your phpinfo

done that

/jason

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Mon, 2012-09-10 19:02
jason@barbanet wrote:
Debugging the module olympus.inc - I use an Olympus camera - it can be shown that whenever I display a photo the function formatOlympusData is called repeteadly until the execution timelimit is hit. And, when I upload photos, the number of times formatOlympusData is called from the function parseOlympus - that is the content of the variable $num - is 4949(!) and thus the function formatOlympusData is called accordingly ...

As stated above, when performing the piece of code below found in olympus.inc as a part of function parseOlympus, $num contains the value 4949. Problably the substr() function is extracting the wrong bytes from $block. Or $block is not containing the correct data field.

//Get number of tags (2 bytes)
$num = bin2hex(substr($block,$place,2));$place+=2;

The string $block begins with

OLYMPUS II

and $place contains 10, where the two characters "II" are found. the ASCII code for I is hex 49. And "II" could be interpreted as little endians according to a standard document.

/jason

 
suprsidr
suprsidr's picture

Joined: 2005-04-17
Posts: 8339
Posted: Mon, 2012-09-10 18:30

Your php is compiled w/ exif support.
Though I've never cracked open the exif module(until now) I'd assume it would rely on php's exif extension.
Yours appears to be the same v. as mine.

It could be that olympus has changed its format in the 9yrs since olympus.inc has been written.
You may want to checkout the exif project to see if there is an updated library for olympus.
olumpus.inc is was not written by the gallery team and unless you find another gallery user who has had a similar issue, you won't likely find help here for it.

-s
All New jQuery Minislideshow for G2/G3

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Mon, 2012-09-10 18:52

Try replacing your olympus.inc file with this version.
(save old version with diff name and change extension of new to .inc)

--
dakanji.com

 
suprsidr
suprsidr's picture

Joined: 2005-04-17
Posts: 8339
Posted: Mon, 2012-09-10 19:23

that looks like the same version same w/ the last release from the project http://www.offsky.com/software/exif/index.php

-s
All New jQuery Minislideshow for G2/G3

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Mon, 2012-09-10 19:30

Not sure, the guy said he stopped dev in 2005, said the zenphoto people will maintain it and the file from zenphoto was apparently last updated in October 2009.

Didn't check the details of the package on his site though.

--
dakanji.com

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Mon, 2012-09-10 19:43

Just checked the file on his site and the zenphoto one is different particularly the "parseOlympus" function which is apparently the problem function according to the OP.

The old file set seems to be the same as the G2 one

--
dakanji.com

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Mon, 2012-09-10 20:01
Dayo wrote:
Try replacing your olympus.inc file with this version

Did that, and it helped while displaying photos. The number of tags is set to 73. But unfortunately upload doesn't even try the functions in olympus-inc. Just getting error reports. Nothing is uploaded. I have tried both Uploadify and the Upload applet.

/jason

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Mon, 2012-09-10 20:33

You might need to download the whole set from zenphoto and rename the individual files to match the G2 structure.

You could also see what is triggering the errors from your logs.

Alternatively, you could try to just change the problem function with the updated one if it is an easy change.

--
dakanji.com

 
jason@barbanet

Joined: 2012-07-02
Posts: 23
Posted: Tue, 2012-09-11 18:22
Dayo wrote:
You might need to download the whole set from zenphoto

My son did this, and it solved the problem both with uploading and displaying. The debian package for Gallery2, version 2.3.2.dfsg-1, most contain old, outdated EXIF moules/files. This bug is reported to debian.org.

Thanks for support.

/jason

 
Dayo

Joined: 2005-11-04
Posts: 1642
Posted: Tue, 2012-09-11 19:31

Actually, this is a Gallery2 issue. The exifer library packed with the exif module appears to be out of date.

It looks like the debian packager is still actively maintaining G2 and they may of course fix this at their end but these sorts of fixes by packagers is what sometimes leads to issues down the line.

Fortunately the issue can be fixed despite G2' status since it is just a matter of updating a module.

Maybe one for suprsidr to look into as updating the G2 plugin repo is a dark art.

--
dakanji.com