Archive for the ‘php’ Category

PHP extensions

Montag, August 15th, 2011

This is a «thank you», going out to all the people taking on the daring, unthankful, and never-completed task of packaging PHP extensions for all the OS and their ever-changing versions out there. Without your work, setting up new systems would be a massive… well, you know.

That being said, if you do so, please take extra care to get your facts straight. If you for example package, say,

php5-pecl-mongo-1.1.4-1.2.x86_64.rpm

for openSUSE 11.3, you should be aware that the person who has to go through the installation, likely already had quite an unfortunate day by having to deal with SUSE in the first place (because, who would take the decision to use it by himself?), and does not want any extra surprises when using an – already hard to find – rpm. The last thing this person wants, is having to deal with fancy ticks of the setup installed.

For example, it would be really annoying to find out, that after the installation your apache does not like to start again, because, strangely, the extension installed with PHP (e.g. /usr/lib64/php5/extensions/mongo.so) can not be found, despite being right there, being owned by the right user, having proper permission, …

Long story short. Do _not_ put any white spaces into the extension’s ini file (e.g. /etc/php5/conf.d/mongo.ini) when trying to describe the location of the extension binary on HDD. Because, even to the trained eye

extension = mongo.so

and

extension = mongo.so

look really „similar“. Do it like the big boys, don’t put any white spaces into said line; especially at the end of the line, where noone will be able to see them (except you make a habit out of unsing a hex editor on everything), even when looking right at the file, suspecting something fishy. Be less human friendly, don’t beautify something, the poor person trying to setup the system doesn’t want to look at – and wouldn’t have had to, if you didn’t.

/rant

Doctrine 1.2.3 Segmentation fault

Samstag, Oktober 9th, 2010

Today we learned, that – with the stars properly aligned – doing the right mistakes in using Doctrine can actually make PHP cause a Segmentation fault.

So far I have not been able to reproduce the problem in an Apache environment; but running PHPUnit from the CLI, the issue could be reproduced consistently.

The root of the evil is using Doctrine’s Behaviour/Templates in an ill-advised way. In this particular situation, a model had a behaviour defined and, at the same time, a custom column definition for columns also specified by the behaviour.

Doctrine does a lot of internal magic — possibility for behaviour parameter validation is unfortunate, though. When creating your own behaviours for example, throwing exceptions to notify the programmer using the behaviour that some of the passed parameters are invalid, Doctrine catches and „swallows“ these so they never can be seen and considered… So far, looking at e.g. unit tests for the build-in behaviours I have not figured out how to do this „right“.

Anyhow, a Segmentation fault should hardly be the result of any configuration mistake. I will try to create a test case in a fresh environment (other that the fair size project this happened in), and take a closer look on how to reliably reproduce the issue and use a debugger to confirm the reason really can be found inside Doctrine’s code or if some other 3rd party software (XDebug, …) has any influence.

Finding PHP4 constructors in Eclipse

Mittwoch, August 11th, 2010

With PHP5.3.3 its time to remove some dust from your old code. Aside of the fact that most of us would want to look into legacy projects, checking for issues someone else has solved more elegantly in the meantime, support for the old contructor names (a function identical to the class name) will be dropped. This means the old code will have to be ported.

As I am not a friend of automated code modification I searched for a way to find concerned classes via the Eclipse file search – using regular expression. This should do…

(?s)^(class\s+(\w+)\b.*^\s+function\s+)\2\b

APC update (3.1.4) – configuration notice

Mittwoch, August 11th, 2010

APC finally follows the standard of using suffixed values for memory sizes specified inside your php.ini (or APC’s dedicated ini). So if you encounter a

PHP Warning: PHP Startup: apc.shm_size now uses M/G suffixes, please update your ini files

while still having something like (e.g. in /etc/php.d/apc.ini)

; The size of each shared memory segment in MB.
apc.shm_size=512

in your configuration, its enough to append the respective unit indicator (M = Mega, G = Giga) to the number in order to update your configuration to comply with the requirements.

apc.shm_size=512M

happy easter — debugging

Montag, April 5th, 2010

At the moment gearman(d) keeps me occupied at work. I am soon going to give (yes, yet another) deeper insight into that.

Aside of the obvious, my first findings boil down to the following

  • When running PHP workers, don’t even try to make them stay alive forever.  Have them commit suicide (sounds dirty but has the advantage that the process itsself knows when its idle) and be reborn on a regular basis. Saves a lot of hassle.
  • Never do the mistake, even if it seems sufficient, to only have one PHP worker running for each gearman server. I had three servers on three individual physical machines, running with one worker each, and all hell rained down (did you ever happen to see a load 500?).