Details here http://www.silexlabs.org/updates-for-amfphp-and-baguette-amf/

It’s mostly a bugfix release. The changelog is below. Get Amfphp 2.2.1 here.

]]> http://arielsommeria.com/blog/2013/12/16/amfphp-2-2-profiler-released/feed/ 0 http://arielsommeria.com/blog/2013/10/31/hacking-amf-objects/ http://arielsommeria.com/blog/2013/10/31/hacking-amf-objects/#comments Thu, 31 Oct 2013 11:11:26 +0000 http://arielsommeria.com/blog/?p=403 While working on the upcoming AmfPHP 2.2 I came upon an interesting challenge: Sending AMF typed objects without knowing the types at compile time.

This would allow users of the service browser to send typed objects both with JSON and AMF.
The difficulty is the following: For Flash to send an object as typed, you must provide an alias for its class. This can be done either with the RemoteClass meta data tag, or with registerClassAlias. This works fine, but is designed with the idea that you know what the alias shall be at compile time. So I had to find a workaround so that the user can state:

“take this object, use this alias, and send it to the server. “

So I ended up doing the following:

1. I created some dynamic empty dummy classes, and made sure they were included in the compiled SWF by including a reference to them in the code.

   package
   {
   public dynamic class Dummy0
   {
   
   }
   }
   

   The classes are public so that I can find them with getDefinitionByName ,and dynamic so that I can add things to them at runtime.
   and the reference in my main class:

   var dummyRef:Class = Dummy0;
   

2. For each new object that needs to be sent that is marked with an alias, I replace it with one of my dummy classes, and call registerClassAlias so that the used dummy is sent with the right alias. The dummyClass is stored in a dictionary, so that I can reuse it for another object with the same alias.

   var dummyClass:Class = null;
   
   if(!type2Class[explicitType]){
   dummyClass = getDefinitionByName("Dummy" + numUsedDummyClasses) as Class;
   type2Class[explicitType] = dummyClass;
   numUsedDummyClasses++;
   }else{
   dummyClass = type2Class[explicitType];
   }
   

3. And I tunnel down the object recursively to make sure this works on many levels.

Is this a hack? Indeed? I would very much like to find a cleaner way to do this. I have considered messing directly with the byte code, but this seems a bit heavy handed.

It’s also only part of the problem: I would very much like to be able to receive typed objects from the server about which the client knows nothing and still be able to retrieve the type. The Flash player unfortunately does not allow this.

The full code as it stands is below. It can also be found online here.

package
{

import flash.display.Sprite;
import flash.external.ExternalInterface;
import flash.net.NetConnection;
import flash.net.Responder;
import flash.net.getClassByAlias;
import flash.net.registerClassAlias;
import flash.utils.Dictionary;
import flash.utils.getDefinitionByName;
import flash.utils.getQualifiedClassName;

/**
* provides AMF calling functionality to the service browser via External Interface.
* exposes a "call" method, a "isAlive" method, and uses 1 callback: "onResult"
* */
public class AmfCaller extends Sprite
{
private var numUsedDummyClasses:int = 0;
private var type2Class:Dictionary = new Dictionary();

public function AmfCaller()
{
ExternalInterface.addCallback("call", call);
ExternalInterface.addCallback("isAlive", isAlive);

//need this to make sure compiler includes dummy classes
var dummyRef:Class = Dummy0;
dummyRef = Dummy1;
dummyRef = Dummy2;
dummyRef = Dummy3;
dummyRef = Dummy4;
dummyRef = Dummy5;
dummyRef = Dummy6;
dummyRef = Dummy7;
dummyRef = Dummy8;
dummyRef = Dummy9;
dummyRef = Dummy10;
dummyRef = Dummy11;
dummyRef = Dummy12;
dummyRef = Dummy13;
dummyRef = Dummy14;
dummyRef = Dummy15;
dummyRef = Dummy16;
dummyRef = Dummy17;
dummyRef = Dummy18;
dummyRef = Dummy19;
}

/**
* a quick way for JS to check that AmfCaller is properly loaded and avaliable
* */
public function isAlive():Boolean{
return true;
}
/**
* make an AMF call
* */
public function call(url:String, command:String, parameters:Array):void{
var netConnection:NetConnection = new NetConnection();
netConnection.connect(url);
var callArgs:Array = new Array(command, new Responder(resultHandler, resultHandler));
for each(var param:* in parameters){
callArgs.push(convertObjectUsingExplicitType(param));

}
netConnection.call.apply(netConnection, callArgs);
}

/**
* callback used both for error and success. calls onResult in JS.
* */
private function resultHandler(obj:Object):void{

ExternalInterface.call("onResult", obj);

}

/**
* replaces an object marked with _explicitType by a Dummy class, and registers the Dummy class with an alias set to _explicitType.
* Yes this is absolutely bending over backwards, and is limited to 20 different explicit types.
* A possible way to override this would be to manipulate the byte code directly but it's more trouble than it's worth.
* Any suggestion on how to do this in a cleaner fashion is welcome.
* */
private function convertObjectUsingExplicitType(obj:*):*{
var type:String = getQualifiedClassName(obj);
if((type != "Array") && (type != "Object")){
return obj;
}

var explicitType:String = obj["_explicitType"];
if(!explicitType){
return obj;
}

//if we're here it means that the object needs to be replaced with one with which we can call registerClassAlias
//so replace by a typed one
var dummyClass:Class = null;

if(!type2Class[explicitType]){
dummyClass = getDefinitionByName("Dummy" + numUsedDummyClasses) as Class;
type2Class[explicitType] = dummyClass;
numUsedDummyClasses++;
}else{
dummyClass = type2Class[explicitType];
}
var ret:Object = new dummyClass();
registerClassAlias(explicitType, dummyClass);

for(var key:String in obj){
if(key == "_explicitType"){
continue;
}
var subObj:* = obj[key];

ret[key] = convertObjectUsingExplicitType(subObj);
}

return ret;
}

}

}

http://www.silexlabs.org/179725/the-blog/amfphp-2-2-teaser-1-putting-your-code-comments-to-good-use/

Please give it a try!

Obviously you’re advised to use Baguette AMF at the end, but I’ve tried to keep things factual, informative, and accessible.

My answer to these requests was to create Baguette AMF.

AMF is a very compact binary format, useful for transferring large amounts of complex data. It is however very demanding for a server. AmfPHP on its own does a good job, but it takes time, as it is written in PHP. Baguette AMF uses C, and therefore enjoys native performance. Install it on your server and enjoy up to 20 times faster conversion times.

It’s been in private beta for a few months, and I haven’t communicated much about it. It’s finally in public beta, so the time has come to get the word out.

Below is a performance chart, comparing server performance with and without Baguette AMF. Notice that for small amounts of data, Baguette AMF doesn’t make much difference. However when transferring large amounts of data, using Baguette AMF can make a huge difference in server performance and response times.

With Baguette AMF you can now enjoy both the low bandwidth of AMF and the server performance you need for your applications.

So please try it out!

http://www.baguetteamf.com/

Please note that this is a commercial project and therefore not directly associated with Silex Labs.

While working on Baguette AMF, the beta testers and myself have run into the dreaded ‘segmentation fault (11)’ error. By default, you won’t get any information in your logs about what happened and you will be powerless to fix the problem. The aim of this post is to explain to you how to be able to use GDB, the GNU (command line) debugger to get a stack trace that will help you find where your code is failing. Once you’re there, you can also do what you can usually do with a debugger, such as step through the code, get variable values etc.

So, there are various ways to do this, but what I’ve found works for me is rebuilding debug versions of Apache, PHP, and my extension.

Before we Start

• Please note that this is not for the faint of heart, that it will require quite some time and patience, and that this tutorial assumes that you know quite a bit about programming, compiling etc. If you have trouble, please comment and I will try to add any missing info.
• You’ll need root access to your server and the source code for Apache, PHP and the extension you want to debug.
• You will need quite a few libraries installed to be able to build Apache and PHP. If you’re on a Mac like myself, I’ve found the simplest is to use MacPorts to install Apache and PHP, and it will install all the dependencies for you.

There are quite a few tutorials out there on the question, but here is the command line anyway. Obviously, install Macports first.

sudo port install php5 +apache2 +mysql5 +pear

Make sure you have a working Apache+PHP5. If you do, it means all the libraries are installed and you can get started for real.

• You’ll also need developer tools such as the GCC compiler. I’ve found the simplest way to get them is to install XCode.

Building Apache for Debugging

First, download and unzip the Apache Source Code. Note that I’ve pointed you to version 2.2. PHP 5.2 and earlier won’t build with 2.4 so it’s important to get the right version.

open a terminal and go to the source code folder. Then:

sudo ./configure CFLAGS=-g --prefix=/usr/local/apache2 --enable_rewrite

./configure is a script that prepares the way so that the ‘make’ script afterwards can work on your system. I’ve added three options that need explaining:

• CFLAGS=-g tells the compiler to add debug symbols, as described here.
• –prefix=/usr/local/apache2 tells the configure script where apache must look for its configuration file. When you install your new apache, its files will be written to /usr/local/apache2. If you don’t set this, it will read its configuration from /etc/local/apache2.
• –enable_rewrite=shared This adds mod_rewrite as a shared module. Not strictly necessary, but if you want to use your Apache with any modern web package then you’ll probably need mod_rewrite.

Then, if your configuration went well:

sudo make clean all install

This executes the ‘clean’, ‘all’ and ‘install’ commands in the makefile.

• Clean gets rid of any intermediate compiled files. It’s not necessary unless you are having trouble building. But I find it’s good practice to include it just in case. Otherwise it’s happened that I see some meaningless error messages that could be solved with a clean.
• all is the actual compilation.
• install does the actual installation, ie writing the various files to your system, mostly in /usr/local/apache2.

If all went well, you can then run this to start your new Apache. Make sure the port you are using (usually 80) is not used before.

sudo /usr/local/apache2/bin/apachectl start

and open your browser, point it to ‘localhost’, and normally you should see ‘It Works’ in your browser.

It works? Good! Onto PHP then.

Building PHP for Debugging

To build PHP I recommend using PHPFarm. It will allow you to switch easily from one PHP version to another. Please note that sometimes the PHP version you want doesn’t build. The simplest is to try with another version. There’s some good extra info on how to use PHPFarm here. PHPFarm messes up the paths slightly for the CLI version of PHP on Macs, but that shouldn’t stop you from using it.

So first build the CLI version of PHP as described in the links above. Then you can move onto to a debug version built for Apache.

My configuration options for building PHP 5.3 are the following:

configoptions="
--with-apxs2=/usr/local/apache2/bin/apxs 
--prefix=/usr/local/apache2/php 
--without-iconv

"

The first 2 tell the script to build for apache and where to put the files. The bit about iconv is because I had trouble building with iconv.

If all went well, you can configure Apache to use PHP. Add the following to your Apache config, and restart it.

LoadModule php5_module        modules/libphp5.so
AddHandler php5-script    .php
AddType application/x-httpd-php .php

#just add the index.php bit, as the DirectoryIndex bit is already there

DirectoryIndex index.html index.php

Now test that you can run some PHP code. Good? On to the PHP extension…

Building your extension

If you got to here, building your extension shouldn’t be too much of an issue. Here’s a typical script:

/php-5.3.2/bin/phpize
./configure --with-php-config=/php-5.3.2/bin/php-config
make clean all

Then make sure in your php.ini that your extension is loaded, check that it actually loads with phpinfo, and try to reproduce that segmentation fault!

Got it? Good. Now onto Debugging…

Getting a stack trace with GDB

In our case we want to run apache+PHP+ our extension, attach GDB to the process that will crash, provoke the crash, and gather whatever info we need to fix the issue.

The thing is, apache has multiple processes. So it’s difficult to know what process is going to crash. The simplest thing to do is to make sure it only runs one child process. So, add this to your apache config:

MaxClients 1

Then you can just run ps or look in the Activity Monitor to get the process number.

Once you can reliably predict which process is going to crash, run the following line(replace 1234 with the relevant process id):

sudo gdb /usr/local/apache2/bin/httpd 1234

This runs gdb on the apache executable, and tells it to attach to the process 1234.

Now make Apache crash!

in gdb type ‘bt’ and you should get a stack trace telling you where your extension’s code failed.

Note: if you don’t see your extension’s code mentioned in the trace, try ‘continue’ then ‘bt’ again.

There you are. Hope that helps, and good luck with debugging!!

Further Reading

Some links that I’ve found helpful:

http://dan.drydog.com/apache2php.html

http://2tbsp.com/content/install_apache_2_and_php_5_macports

http://www.viraj.org/b2evolution/blogs/index.php/2005/09/15/the_art_of_debugging_apache_segfaults

http://httpd.apache.org/dev/debugging.html

http://xerces.apache.org/xerces-c/build-3.html

http://www.silexlabs.org/136374/the-blog/amfphp-survives-zend-amf/