PHP: Fixing Mismatched Canaries – How to Remove suhosin from Debian/Ubuntu Packages

30 August 2009: Will’s comment notes that Debian Squeeze now has an updated php5-suhosin package that may fix the problem I discuss below.

Having recently moved our development environment at work to a stock Debian 5 machine, some of our PHP code was throwing the following strange error in the apache (not the PHP) error log:

canary mismatch on efree() - heap overflow detected ...

After some research, it turns out this somewhat strange error is caused by the suhosin patch that is compiled into Debian’s default PHP5 package. In my case, it was some calls to mssql_query were throwing the error in Apache.

Updating the php.ini file to switch suhosin into simulation mode (as suggested by the documentation) didn’t have any effect, so I set about recompiling PHP5 into a new deb package without the suhosin patch.

This was the best tutorial I found for recompiling the deb. I’ve recreated the instructions below:

Create a working folder somewhere on your machine:

$ mkdir ~/packages
$ cd ~/packages

Install the Debian development packages

$ sudo apt-get install devscripts
$ sudo apt-get install gcc debhelper fakeroot
$ apt-get source php5
$ sudo apt-get build-dep php5

These lines will install the development helper scripts, and download the source files for PHP5 and its dependencies.

Remove references to the suhosin patch

$ cd php5-x.y # This will depend on the version of PHP
$ rm debian/patches/suhosin.patch

You now need to remove the instruction to include suhosin in the compiled package. I’ve used vim, but you can use any text editor.

$ sudo vim debian/patches/series

Once open, remove the line referencing suhosin.patch

Increment the package version
Incrementing the version will ensure that your custom package is installed by apt-get. You can use the debchange script to achieve this. You should avoid mentioning suhosin in the version name, and instead append a custom version string, e.g:

$ debchange -v 5.2.6-1debian.5.0~custom1 # 5.2.6 was my distro's default version. Again, change to match the default php version for your distrubution

Your text editor will open, and you should update the changelog to mention that you have removed the suhosin patch.

Compile and Build the Package

$ debuild

The build took a while on my machine, so now’s a great time to grab a brew.

Once finished, you should have a set of debs ready to install in the parent folder (../php5…).

$ dpkg -i php5-x.y.z.deb php5-common-x.y.z.deb php5-sybase-x.y.z.deb
# Include any additional packages you use, e.g. php-pear
php5 php5-common php5-sybase (the PHP5 MSSQL connector package)

The build process also creates a libapache2-mod-php5 package which I had to install to use the custom of build of PHP5 through Apache using dpkg:

$ dpkg -i libapache2-mod-php5-x.y.z # Use the new PHP5 in Apache2

Via: Original Instructional Post[http://ambitonline.com/]

J2ME Uploading Images to PHP Script

8 March 2011 Kutay Ozdogru has posted a recent, complete example of how to upload images via J2ME to PHP on the Nokia forums.

I’ve posted this as a helpful pointer to those looking into J2ME server interaction, and as a reminder to myself when I am next trying to figure out uploading J2ME images to PHP.

Something that constantly eluded me through the development of Toupix was an elegant way to get images from a phone to the server. Due to deadlines, I eventually decided to submit the image as an email and use PHP’s IMAP functionality to read and decode the email. Whilst functional, this wasn’t exactly the solution to end all solutions.

What frustrated me the most is that this should be something relatively simple, yet days and days of frustrating research and playing around with various encoding algorithms still resulted in invalid images being saved. The data was being received by the script, but something was getting garbled.

So, finally, I have discovered the solution – and it’s incredibly simple. Browsing forums, it is clear that the image data needs to be encoded into a Base64 string, and Stefan Haustein’s Base64 class provides the ideal method for doing this. Using Base64.encode(), the raw byte array of an image is returned as Base64 string.

public static boolean uploadImage( String uri, byte[] rawImage, String filename )
throws Exception
{
HttpConnectionhttpConnection;
OutputStream    out;
 
// Open connection to the script
httpConnection          = (HttpConnection)Connector.open( uri );
 
// Setup the request as an HTTP POST and encode with form data
httpConnection.setRequestMethod( HttpConnection.POST );
httpConnection.setRequestProperty( "Content-type", "application/x-www-form-urlencoded" );
 
// Encode the imagedata with Base64
String    encoded    = Base64.encode( rawImage ).toString();
 
// Build the output and encoded string
String    output    = "file=" + filename + "&imgdata=" + encoded;
 
// Set the content length header
httpConnection.setRequestProperty("Content-Length", Integer.toString((output.getBytes().length)));
 
// Open the output stream and publish data
out = httpConnection.openOutputStream();
out.write( output.getBytes() );
 
// Flush the buffer (might not be necessary?)
out.flush();
 
// Here you might want to read a response from the POST to make
// sure everything went OK.
 
// Close everything down
if( out != null )
if( httpConnection != null )
httpConnection.close();
 
// All good
return true;
}

The next step is to get this string published to the server (PHP script). This is where the problems started. Most documentation I found assumed we are uploading to a JSP script, and there is little mention of PHP. The easiest way to get our data to PHP is via HTTP POST, and since our image is now a normal string, we can happily POST it to the server. The PHP script on the server can then read the string via the normal $_POST[] variable, and (theoretically) decode it:

...
//Decode the image from Base64 encoding
$img= base64_decode( $data );
 
//Write out data to file
if( $fp = fopen( $out, 'wb' ) )
{
//Write data to the file
fwrite( $fp, $img );
 
//Close the file
fclose( $fp );
}
else
{
die( "Error writing to image file $out" );
}
...

Unfortunately, though, something seems to happen to the data when it arrives on our server. It is at this point that everything was going wrong; the data was corrupt by the time it was decoded, and thus the image file produced was invalid. It turns out (and it had to be so simple) that we need to strip the Base64 string of spaces, and replace them with a + character!

function stripLineBreaks( $encode )
{
$data= str_replace( ' ', '+', $encode );
//$data= str_replace( 'rn', '', $data );
return $data;
}

Now, before decoding the base64 string, just run it through this function first:

...
//Decode the image from Base64 encoding
$data= stripLineBreaks( $data );
$img= base64_decode( $data );
 
//Write out data to file
...

At last, an image uploaded to your server via a J2ME MIDlet (under emulation – I’m using the Sony WTK set to use HTTP1.0). There are likely to be issues running it on a phone or emulator under HTTP1.1. My server doesn’t handle chunked data, which HTTP1.1 enforces by breaking the sent image data into chunks. This forum post shows a possible way around this, and if I find a successful method I’ll be sure to post it!

Was this post useful? Please leave me your comments and feedback.