msgpack/msgpack-php

msgpack.org[PHP]

MessagePack

MessagePack is an efficient binary serialization format. It's like JSON. but fast and small.

This repository manages specification of MessagePack format. See Spec for the specification.

Implementation projects have each own repository. See msgpack.org website to find implementations and their documents.

If you'd like to show your msgpack implementation to the msgpack.org website, please follow the website document.

msgpack-php's Issues

session serialize handler adds a null key

I am using the msgpack session serialize handler in latest release from pecl (0.5.6). I tested this with both file and redis save handlers.

Here is the php array that is serialized in the session :
array(1) { ["acl_user"]=> array(2) { ["id"]=> string(10) "NGwnGUqwsr" ["status"]=> int(2) } }

Here is the result I expect (without ws added for readability...) :

               \x81 \xa8 acl_user \x82     \xa2 id   \xaa NGwnGUqwsr   \xa6 status \x02

Here is the result I get :

\x82     \xc0 \x01  \xa8 acl_user \x82     \xa2 id   \xaa NGwnGUqwsr   \xa6 status \x02

It looks like there is a null indexed value of 1 added before getting to the expected array (I am no expert in msgpack decoding, so I might be wrong...).

This null indexed value makes it impossible to share session with other tools (like Lua in Redis for example) because null (or nil) cannot be used as a key to index a value.

Is it possible to get rid of this null indexed value that seems useless ?

Throw exceptions when not possible to unpack

We're attempting to include MsgPack as one possible serializer for our suite but we found the problem that when it is not possible to unpack data, msgpack_unpack triggers an error.

This is a big problem because in PHP it is not possible to capture a PHP error and act accordingly, so I propose two solutions:

• Create a MessagePackException that is thrown whenever an error occurs. This can be easily try/catch'ed in a controlled way. This would be great por the OO API (MsgPack class).
• Return a specific value when a problem occurs (false, for example) and add a msgpack_last_error() function that returns information about how it was the last unpack operation. This is the behaviour used by the JSON lib on PHP. http://www.php.net//manual/en/function.json-last-error.php

鸟哥，在windows上部署了yar，调用Yar_Concurrent_Client::loop出错

在调用github里的一个例子时，出了下面的警告
Warning: Yar_Concurrent_Client::loop(): can not get fd from curl instance

a PHP Warning

when i call msgpack_unpack function , i got a PHP Warning .
"PHP Warning: msgpack php_msgpack_unserialize Extra bytes in..."

but i used msgpack-c to serialize and msgpack-php to deserialize.

my environment :
php-5.3.27
msgpack-c-cpp-0.5.9
msgpack-0.5.5 +

gg

急求msgpack增加一个msgpack_unpack($data, true)的逻辑

@laruence 鸟哥，急求msgpack增加一个msgpack_unpack($data, true)的逻辑，类似json_decode($data, true)，把结果全部转成数组，如果有object;

用于从json切换时的兼容性

"Invalid read" reported by valgrind

run tests/090.phpt with valgrind shows:
==4364== Invalid read of size 1
==4364== at 0x8E590C: zend_mangle_property_name (zend_compile.c:5028)
==4364== by 0x5B11BA3: msgpack_convert_string_to_properties (msgpack_convert.c:150)
==4364== by 0x5B13418: msgpack_convert_object (msgpack_convert.c:598)
==4364== by 0x5B13EEE: msgpack_convert_template (msgpack_convert.c:783)
==4364== by 0x5B07769: zif_msgpack_unserialize (msgpack.c:337)
==4364== by 0x949C1A: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==4364== by 0x951AF3: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2223)
==4364== by 0x948215: execute (zend_vm_execute.h:410)
==4364== by 0x909774: zend_execute_scripts (zend.c:1315)
==4364== by 0x871CFF: php_execute_script (main.c:2492)
==4364== by 0xA5F983: do_cli (php_cli.c:988)
==4364== by 0xA60B32: main (php_cli.c:1364)
......

Segfault on session php 7

Hello when using session.serialize_handler = "msgpack" I get a segfault error.

I am using PHP 7.0RC5 with php7-fpm and nginx with msgpack-php branch php7. Debian 7.9

This is the core dump.

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `php-fpm: pool www                                                             '.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fbd06d6d60b in ps_srlzr_decode_msgpack (
    val=0x7fbd088777f8 "symfony/user/sfUser/lastRequest|i:1445232500;symfony/user/sfUser/authenticated|b:0;symfony/user/sfUser/credentials|a:0:{}symfony/user/sfUser/attributes|a:0:{}symfony/user/sfUser/culture|s:2:\"en\";", vallen=195) at /root/msgpack-php/msgpack.c:178
#1  0x000000000069a8ff in php_session_decode (data=<optimized out>) at /php-7-debian/php-src/ext/session/session.c:237
#2  0x000000000069d9ae in php_session_initialize () at /php-7-debian/php-src/ext/session/session.c:541
#3  0x000000000069e1cd in php_session_start () at /php-7-debian/php-src/ext/session/session.c:1623
#4  0x000000000069ead7 in zif_session_start (execute_data=<optimized out>, return_value=0x7fbd08815570) at /php-7-debian/php-src/ext/session/session.c:2301
#5  0x0000000000869db2 in ZEND_DO_ICALL_SPEC_HANDLER (execute_data=0x7fbd08815480) at /php-7-debian/php-src/Zend/zend_vm_execute.h:586
#6  0x000000000085aaa0 in execute_ex (ex=<optimized out>) at /php-7-debian/php-src/Zend/zend_vm_execute.h:417
#7  0x00000000008aaf37 in zend_execute (op_array=op_array@entry=0x7fbd08877000, return_value=return_value@entry=0x0) at /php-7-debian/php-src/Zend/zend_vm_execute.h:458
#8  0x000000000081e094 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /php-7-debian/php-src/Zend/zend.c:1428
#9  0x00000000007c00e0 in php_execute_script (primary_file=primary_file@entry=0x7fffdd0052c0) at /php-7-debian/php-src/main/main.c:2471
#10 0x000000000044739e in main (argc=<optimized out>, argv=<optimized out>) at /php-7-debian/php-src/sapi/fpm/fpm/fpm_main.c:1944

when will msgpack php v5 version be released?

I'd like to know when msppack php v5 version will be released, we have a project rely on this. Thanks!

MessagePack::OPT_PHPONLY on false - object serialized to array without keys

When msgpack packs object with PHPONLY option set on false, it returns array without key names. I don't think it's correct behavior.

class Test {
    private $privateProperty = 'some value';
    protected $protectedProperty = 'some value';
    public $property = 'some value';
}

$o = new Test();
$msgpack = new MessagePack(false);
print_r($msgpack->unpack($msgpack->pack($o)));

$msgpack = new MessagePack(true);
print_r($msgpack->unpack($msgpack->pack($o)));

Output

Array
(
    [0] => some value 
    [1] => some value
    [2] => some value
)
Test Object
(
    [privateProperty:Test:private] => some value
    [protectedProperty:protected] => some value
    [property] => some value
)

PHP 5.5.14 and session.serializer crash

I recently encountered an issue with using msgpack as session.serializer with PHP 5.5.14:

PHP Warning:  [msgpack] (msgpack_serialize_zval) type is unsupported, encoded as null in Unknown on line 0

It causes my apps to crash, so I have reverted to "php" as serializer for now.

PHP 5.5.14, msgpack 0.5.5, CentOS 6.3 64-bit

int64 and uint64 decode is not supported in 32-bit php？

hi.
I get a problem, in 32-bit php decode int64 is error. I think the problem maybe is here.

int msgpack_unserialize_int64(
    msgpack_unserialize_data *unpack, int64_t data, zval **obj)
{
    ZVAL_LONG(*obj, data);
    return 0;
}

int msgpack_unserialize_int64(
msgpack_unserialize_data _unpack, int64_t data, zval *_obj)
{
if(data > LONG_MAX || data < -LONG_MAX) {
ZVAL_DOUBLE(_obj, (double)data);
} else {
ZVAL_LONG(_obj, data);
}
return 0;
}

why I got a string(1) "€" when I use msgpack_serialize to serialize a object

When I use msgpack_serialize to serialize a object didn't have any property ,It will return a string(1) "€" , the code like this:
class Obj { public function run() { $xx = new self(); // $xx->main(); // $xx = $get; $a = msgpack_serialize($xx); $aa = msgpack_unserialize($a); $aaa = bin2hex($a); var_dump($a,$aa,$aaa);
the rs is:
string(1) "€" object(stdClass)#2 (0) { } string(2) "80"

But if the object have any property, the rs will be right,why?

Broken big on PowerPC (bigendian)

Build is ok, but lot of failed tests.

 FAILED TEST SUMMARY
 ---------------------------------------------------------------------
 broken random data test : MessagePackUnpacker::execute [tests/040d.phpt]
 Check for unbuffered streaming unserialization [tests/061.phpt]
 Extra bytes unbuffered streaming unserialization [tests/063.phpt]
 Check for unbuffered streaming unserialization (single) [tests/065.phpt]
 Extra bytes unbuffered streaming unserialization (single) [tests/067.phpt]
 Check for class methods unpacker [tests/072.phpt]
 Check for class unpacker [tests/073.phpt]
 disabled php only for class methods unpacker (ini_set) [tests/082.phpt]
 disabled php only for class unpacker (ini_set) [tests/083.phpt]
 disabled php only for class methods unpacker (constract) [tests/085.phpt]
 disabled php only for class unpacker (constract) [tests/086.phpt]
 disabled php only for class methods unpacker (set option) [tests/088.phpt]
 disabled php only for class unpacker (set option) [tests/089.phpt]

I know that msgpack have bigendian support in 0.5.8

I don't have access to any ppc64 machine for now, but keep this for later on my TODO list.

Add code coverage support

Hey @laruence
I ported mailparse, and when adding travis-ci support I also looked into beefing up the tests. After I got gcov working I decided to expand and get it online.

Install the codecov extension and then open mailparse.c I now get built into github coverage per file from the test suite, it is really helping me write more comprehensive tests. Also here is the .travis.yml

• You think this is worth adding to msgpack?
• You think this is something worth adding to every PHP extension that is on GitHub? How could I tell people to check this out?

Make a doc

it is better to make a API doc for msgpack

thanks

msgpack_unpack() returns success while there's 'Extra bytes' warning

Hello, when I use msgpack_unpack() to unpack some data, it returns success and there's PHP Warning:
[msgpack] (php_msgpack_unserialize) Extra bytes in a.php on line 4

Is there any way to capture this kind of error? since it returns success I can't differentiate it from normal success situation.

Thanks!

Crash in PHP7 when Unserializing

Here is an object that will serialize/unserialize just fine using PHP's serialize function. serialize() file uploaded as serialize.txt

When serializing with msgpack_serialize, it works, but unserializing using msgpack_unserialize causes core dump. msgpack_serialize() file uploaded as msgpack.txt

Please email me if you need the core dump, caleblloyd on gmail.

PHP 7 build is PHP7 RC 7
MSGPack built from source on PHP7 branch from commit 034ddac

Backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000008a32a2 in zend_std_read_property (object=<optimized out>, member=0x7fff6b61bef0, type=0, cache_slot=<optimized out>, rv=0x0) at /usr/local/php7/src/php-src/Zend/zend_object_handlers.c:565
565             *guard &= ~IN_GET;
(gdb) bt
#0  0x00000000008a32a2 in zend_std_read_property (object=<optimized out>, member=0x7fff6b61bef0, type=0, cache_slot=<optimized out>, rv=0x0) at /usr/local/php7/src/php-src/Zend/zend_object_handlers.c:565
#1  0x0000000000876154 in zend_read_property (scope=<optimized out>, object=0x7f8b1f21f020, name=0x7f8b2cff43e4 "_e", name_length=2, silent=<optimized out>, rv=0x0) at /usr/local/php7/src/php-src/Zend/zend_API.c:3994
#2  0x00007f8b2c004a42 in msgpack_unserialize_map_item (unpack=0x7fff6b61c0b0, container=0x7fff6b61e140, key=0x7f8b1f224000, val=0x7f8b1f224010) at /usr/local/php7/src/msgpack-php/msgpack_unpack.c:614
#3  0x00007f8b2bffebd7 in template_execute (ctx=ctx@entry=0x7fff6b61c0b0, data=data@entry=0x7f8b2cfcf618 "\222\222\225\336", len=len@entry=2072, off=off@entry=0x7fff6b61c088)
at /usr/local/php7/src/msgpack-php/msgpack/unpack_template.h:370
#4  0x00007f8b2bfff68b in php_msgpack_unserialize (return_value=return_value@entry=0x7f8b2ce127a0, str=0x7f8b2cfcf618 "\222\222\225\336", str_len=2072) at /usr/local/php7/src/msgpack-php/msgpack.c:223
#5  0x00007f8b2bfff8d8 in zif_msgpack_unserialize (execute_data=<optimized out>, return_value=0x7f8b2ce127a0) at /usr/local/php7/src/msgpack-php/msgpack.c:285
#6  0x00000000008b8d7d in ZEND_DO_ICALL_SPEC_HANDLER () at /usr/local/php7/src/php-src/Zend/zend_vm_execute.h:586
#7  0x00000000008aa1db in execute_ex (ex=<optimized out>) at /usr/local/php7/src/php-src/Zend/zend_vm_execute.h:414
#8  0x00000000008fdad7 in zend_execute (op_array=0x7f8b2ce68000, op_array@entry=0x7f8b22005ea8, return_value=return_value@entry=0x7f8b2ce12720) at /usr/local/php7/src/php-src/Zend/zend_vm_execute.h:458
#9  0x000000000086b603 in zend_execute_scripts (type=type@entry=8, retval=0x7f8b2ce12720, retval@entry=0x0, file_count=file_count@entry=3) at /usr/local/php7/src/php-src/Zend/zend.c:1428
#10 0x000000000080c840 in php_execute_script (primary_file=0x7fff6b6287a0) at /usr/local/php7/src/php-src/main/main.c:2471
#11 0x000000000044a478 in main (argc=29187783, argv=0x1bd604c) at /usr/local/php7/src/php-src/sapi/fpm/fpm/fpm_main.c:1944

msgpack.txt
serialize.txt

Unsafe, no basic or "JSON mode" (deserialisation of objects)...

Msgpack preserves object types on deserialisation but it is not safe to do this. A user can maliciously set properties and choose the class to instantiate of their choice. Such properties might be a file to include.

As a result this makes msgpack for PHP unsafe by design to use externally

Simple example of json versus msgpack:

$:/# php -r "var_dump(json_decode(json_encode(new DateTime())));var_dump(msgpack_unpack(msgpack_pack(new DateTime())));"
class stdClass#1 (3) {
public $date =>
string(19) "2014-06-09 00:59:34"
public $timezone_type =>
int(3)
public $timezone =>
string(3) "UTC"
}
class DateTime#1 (3) {
public $date =>
string(19) "2014-06-09 00:59:34"
public $timezone_type =>
int(3)
public $timezone =>
string(3) "UTC"
}

I believe a mode should be provided for both pack and unpack so that msgpack can be used as a true drop in replacement for JSON. Right not the library claims this but it is more high level like SOAP XML serialisation, php serialize, igbinary, etc.

implicit declaration of 2 functions

During build (with -Wall)

/dev/shm/BUILD/php-pecl-msgpack-0.5.5/msgpack-0.5.5/msgpack.c:150:5: warning: implicit declaration of function 'msgpack_serialize_var_init' [-Wimplicit-function-declaration]
/dev/shm/BUILD/php-pecl-msgpack-0.5.5/msgpack-0.5.5/msgpack.c:162:5: warning: implicit declaration of function 'msgpack_serialize_var_destroy' [-Wimplicit-function-declaration]

Trivial fix : add function prototype in msgpack_unpack.h (as this functions are defined in msgpack_unpack.c).

Simple class import like Javascript?

For those who can't install module on the server, can we have a "simple" class like the one for Javascript?

Fatal error: Call to undefined function msgpack_pack()

I got this .dll/binary that matches my current php version, load works, as you can see (phpinfo()):

MessagePack Support enabled
Session Support enabled
extension Version 0.5.5
header Version 0.5.4

Directive Local Value Master Value
msgpack.error_display On On
msgpack.illegal_key_insert Off Off
msgpack.php_only On On

But when I try to to call msgpack_pack() i got a fatal error telling me the function does not exist.

Link of .dll: http://windows.php.net/downloads/pecl/releases/msgpack/0.5.5/php_msgpack-0.5.5-5.5-ts-vc11-x64.zip

PHP version is 5.5.12 running on windows

Deserializing a large array of nested objects gives "zend_mm_heap corrupted"

Unserializing largish object collections aborts php with "zend_mm_heap_corrupted".

Unfortunately I can't produce a testcase yet, since the data this happened with is company confidential.
I try to come up with a synthetic case though.

It is an array, that contains 50 php objects. The serialized payload is 517466 characters.

With USE_ZEND_ALLOC=0 I get this:

php(32501) malloc: *** error for object 0x7fe65ab2b048: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Stacktrace:

Application Specific Information:
*** error for object 0x7fbd8232b028: incorrect checksum for freed object - object was probably modified after being freed.

objc[32539]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff87f0182a __kill + 10
1 libsystem_c.dylib 0x00007fff8a571a9c abort + 177
2 libsystem_c.dylib 0x00007fff8a5934ac szone_error + 459
3 libsystem_c.dylib 0x00007fff8a5934e8 free_list_checksum_botch + 29
4 libsystem_c.dylib 0x00007fff8a59a38c tiny_malloc_from_free_list + 145
5 libsystem_c.dylib 0x00007fff8a59b00e szone_malloc_should_clear + 1115
6 libsystem_c.dylib 0x00007fff8a5d03c8 malloc_zone_malloc + 77
7 libsystem_c.dylib 0x00007fff8a5d11a4 malloc + 44
8 php 0x000000010f40fa2f _estrdup + 63
9 php 0x000000010f3e197e sapi_send_headers + 110
10 php 0x000000010f36fc99 php_header + 9
11 php 0x000000010f3e8ece php_ub_body_write + 78
12 php 0x000000010f3d799d php_printf + 157
13 php 0x000000010f3d89a4 php_error_cb + 1492
14 php 0x000000010f42ac45 zend_error + 469
15 msgpack.so 0x000000011270df63 php_msgpack_unserialize + 227 (msgpack.c:254)
16 msgpack.so 0x000000011270d055 zif_msgpack_unserialize + 85 (msgpack.c:331)
17 php 0x000000010f4917f9 zend_do_fcall_common_helper_SPEC + 1081
18 php 0x000000010f491ef1 execute + 609
19 php 0x000000010f42a968 zend_execute_scripts + 440
20 php 0x000000010f3d6872 php_execute_script + 722
21 php 0x000000010f4a8f01 main + 4529
22 php 0x000000010f2637d4 start + 52

force msgpack_pack treat empty array as a map

Hello,
when use msgpack_pack() to pack an empty array, it is always treated as an array, but sometimes we want it to be treated as an empty map, just like what JSON_FORCE_OBJECT does for json_encode(). Does msgpack_pack() has options like this?

Thanks you.

Integer overflow on a 64-bit system

Unpacking 64-bit unsigned integer will result in a negative value if the value is bigger than 2^63 (as PHP does not support unsigned integers):

php > var_dump(msgpack_unpack("\xcf"."\xff\xff\xff\xff"."\xff\xff\xff\xff"));
int(-1)

But PHP's behavior in such cases is to fall back to float/double:

If PHP encounters a number beyond the bounds of the integer type, it will be interpreted as a float instead. Also, an operation which results in a number beyond the bounds of the integer type will return a float instead.

php > var_dump(PHP_INT_MAX + 1);
double(9.2233720368548E+18)
php > var_dump(hexdec('ffffffff'.'ffffffff'));
double(1.844674407371E+19)

I wonder if it would be reasonable to get msgpack_unpack() in line with PHP engine? Or return a string representation of the value?

Release one package

Hi:
I am thinking of make a release(maybe a tag, or branch), let more people to test with it..

what do you think?

thanks

Homebrew-php

Hello,

I am one of the maintainers of https://github.com/josegonzalez/homebrew-php
Did you know that msgpack PECL extension has been added to our formulae ?

Feel free to test it and to update your installation instructions for Mac OSX users.

Happy coding !

Lucas

MsgPack spec v5 support

Looking through the code for this library, it appears that v5 of the MsgPack protocol is not supported. See https://github.com/msgpack/msgpack/blob/master/spec.md, with some of the big changes at the time being that RAW is now split into str & bin 8/16/32 types. Looking at the unpacker, I don't see any mention of these new types.

What is the status on this, and does anyone currently have plans to add support for the MsgPack protocol v5?

Return on unserialization

It returns an unexpected value and issue an E_WARNING when the string is unserializable .
It will be more clear if returns FALSE in this situation, so we will know if the string is successfully unserialized. It will be much better if it throws an exception , since even a serialize FALSE can be unserialized to FALSE.

Unable to load dynamic library undefined symbol: ps_globals in Unknown on line 0

https://gist.github.com/armando-basile/94afc76c91b384cd4297#file-msgpack-with-php-5-6

could you help me

Packing/unpacking the bin format family

Packing/unpacking bin data fails for me:

var_dump(bin2hex(msgpack_pack("\x80")));

Expected: string(6) "c40180"
Actual: string(4) "a180"

var_dump(bin2hex(msgpack_unpack("\xc4\x01\x80")));

Expected: string(2) "80"
Actual: PHP Warning: [msgpack] (php_msgpack_unserialize) Parse error in ...

$ pecl list

INSTALLED PACKAGES, CHANNEL PECL.PHP.NET:
=========================================
PACKAGE VERSION STATE
msgpack 0.5.6   beta

$ php -v

PHP 5.5.9-1ubuntu4.14 (cli) (built: Oct 28 2015 01:34:46)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

Windows Binary

Is there any windows binary for Message pack ?

msgpack_seriallize interfere with php serialize

Test script:

Segfault when use msgpack as session serialize handler at PHP7

hi.
I am testing PHP7 for my system.
When I set the session serialize handler to msgpack, I got a segfault and it will never work.
Msgpack pack and unpack method itself works fine.

I write a simple test code like below.

<?php
ini_set('session.serialize_handler', 'msgpack');

session_start();
$_SESSION['cnt'] = isset($_SESSION['cnt']) ? $_SESSION['cnt'] + 1 : 0;
echo $_SESSION['cnt'];

This is the core dump below.

Program received signal SIGSEGV, Segmentation fault.
0x00007fffd7e6c3a7 in ps_srlzr_decode_msgpack (val=0x7fffe7e540b8 "\202\300\001\243cnt", vallen=8) at /root/php7_modules/msgpack-php-php7/msgpack.c:175
175                     ZEND_HASH_FOREACH_STR_KEY_VAL(HASH_OF(&tmp), key_str, value) {
(gdb) bt
#0  0x00007fffd7e6c3a7 in ps_srlzr_decode_msgpack (val=0x7fffe7e540b8 "\202\300\001\243cnt", vallen=8) at /root/php7_modules/msgpack-php-php7/msgpack.c:175
#1  0x00007fffeafd60ff in php_session_decode (data=<optimized out>) at /root/php-src-php-7.0.0RC4/ext/session/session.c:237
#2  0x00007fffeafd928e in php_session_initialize () at /root/php-src-php-7.0.0RC4/ext/session/session.c:541
#3  0x00007fffeafd9a85 in php_session_start () at /root/php-src-php-7.0.0RC4/ext/session/session.c:1623
#4  0x00007fffeafdad4a in zif_session_start (execute_data=<optimized out>, return_value=0x7fffe7e11090) at /root/php-src-php-7.0.0RC4/ext/session/session.c:2301
#5  0x00007fffeb127eed in ZEND_DO_ICALL_SPEC_HANDLER () at /root/php-src-php-7.0.0RC4/Zend/zend_vm_execute.h:586
#6  0x00007fffeb11b44b in execute_ex (ex=<optimized out>) at /root/php-src-php-7.0.0RC4/Zend/zend_vm_execute.h:414
#7  0x00007fffeb1647b7 in zend_execute (op_array=0x7fffe7e68000, op_array@entry=0x7fffcd7e4270, return_value=return_value@entry=0x7fffe7e11030) at /root/php-src-php-7.0.0RC4/Zend/zend_vm_execute.h:458
#8  0x00007fffeb0e04f4 in zend_execute_scripts (type=type@entry=8, retval=0x7fffe7e11030, retval@entry=0x0, file_count=file_count@entry=3) at /root/php-src-php-7.0.0RC4/Zend/zend.c:1428
#9  0x00007fffeb085470 in php_execute_script (primary_file=primary_file@entry=0x7fffffffdf30) at /root/php-src-php-7.0.0RC4/main/main.c:2471
#10 0x00007fffeb1660a2 in php_handler (r=<optimized out>) at /root/php-src-php-7.0.0RC4/sapi/apache2handler/sapi_apache2.c:678
#11 0x0000555555593150 in ap_run_handler ()
#12 0x0000555555593699 in ap_invoke_handler ()
#13 0x00005555555a7a1a in ap_process_async_request ()
#14 0x00005555555a7cf4 in ap_process_request ()
#15 0x00005555555a4682 in ap_process_http_connection ()
#16 0x000055555559c720 in ap_run_process_connection ()
#17 0x00007fffeda1980f in child_main () from /etc/httpd/modules/mod_mpm_prefork.so
#18 0x00007fffeda19a0c in make_child () from /etc/httpd/modules/mod_mpm_prefork.so
#19 0x00007fffeda1a791 in prefork_run () from /etc/httpd/modules/mod_mpm_prefork.so
#20 0x000055555557950e in ap_run_mpm ()
#21 0x0000555555572b36 in main ()

Some extra info below:

• CentOS Linux release 7.1.1503
• PHP 7.0.0RC4
• Apache/2.4.6

This is a very major issue to me so hope this help.

msgpack打包一个size为0的map,php会解析成一个空对象，如何将其解析为一个空数组

msgpack打包一个size为0的map,php会解析成一个空对象，如何将其解析为一个空数组？

PHP Warning: [msgpack] (php_msgpack_unserialize) Parse error in

Why throw this error, in some condition is ok, but other get this error:

PHP Warning: msgpack Parse error in;

try this code:

php -c /etc/php5/fpm/php.ini -r "var_dump(msgpack_unserialize(base64_decode('3AAdrGFvanBxMjNCcDVlaNkkYzgxZmJlNjAtMzg4NC00ZWZlLWFlZjQtNjZlOGEzMzcwYWNlrzY5MTEwODI2MDY3OTU2M7E2QTo2MzpBRTpEQTo0Mzo1MKCgsjY4MTU0OTI2MTgyMDY2MTc2MKCgoKCgoAGiREWgoKCgoKCm5YW25LuWoM5WMyPDoKCgoKJlbg==')));"

I use python to do same unpack, it success!

msgpack.unpackb(base64.b64decode('3AAdrGFvanBxMjNCcDVlaNkkYzgxZmJlNjAtMzg4NC00ZWZlLWFlZjQtNjZlOGEzMzcwYWNlrzY5MTEwODI2MDY3OTU2M7E2QTo2MzpBRTpEQTo0Mzo1MKCgsjY4MTU0OTI2MTgyMDY2MTc2MKCgoKCgoAGiREWgoKCgoKCm5YW25LuWoM5WMyPDoKCgoKJlbg=='))
['aojpq23Bp5eh', 'c81fbe60-3884-4efe-aef4-66e8a3370ace', '691108260679563', '6A:63:AE:DA:43:50', '', '', '681549261820661760', '', '', '', '', '', '', 1, 'DE', '', '', '', '', '', '', '\xe5\x85\xb6\xe4\xbb\x96', '', 1446192067, '', '', '', '', 'en']

test

guide :

1,1=>2,2=>3); $msg = msgpack_pack($data); $data = msgpack_unpack($msg); ?>

---

//##test case #
$array = array('1' => '111111', '2' => '22222');

case 1:

var_dump(msgpack_pack($array));

case 2:

var_dump(msgpack_unpack('?\001?\000???\002?\000\003d\016"'));

---

case 1 output:

string(16) "?\001?111111\002?22222"

case 2 output:

PHP Warning: msgpack Extra bytes in /WorkSpace/nala/erp/test.php on line 58
PHP Stack trace:
PHP 1. {main}() /WorkSpace/nala/erp/test.php:0
PHP 2. msgpack_unpack() /WorkSpace/nala/erp/test.php:58

Warning: msgpack Extra bytes in /WorkSpace/nala/erp/test.php on line 58

Call Stack:
0.0003 234248 1. {main}() /WorkSpace/nala/erp/test.php:0
0.0331 983072 2. msgpack_unpack() /WorkSpace/nala/erp/test.php:58

Wierd var_dump() output for unserialized objects

Is there a reason to dump unserialized objects to such a specific format?

object(Obj)#%d (3) {
  ["a"]=>
  int(1)
  [%r"?b"?:protected"?%r]=>
  int(2)
  [%r"?c"?:("Obj":)?private"?%r]=>
  int(3)
}

To compare, here is a standard var_dump() output for the same object (https://3v4l.org/nXGBP):

object(Obj)#1 (3) { 
  ["a"]=> 
  int(1) 
  ["b":protected]=> 
  int(2) 
  ["c":"Obj":private]=> 
  int(3) 
}

Object property serialization order

I run into a problem while trying to deserealize data which was serialized using Lua. Here is a simplified example:

po = []
po[msgpack.NULL] = 'stdClass'
po['foo'] = 'bar'
packed = msgpack.encode(po)

As Lua doesn't support ordered hash tables, po keys can be in any order, and most of the time I get {foo: 'bar', "\0": 'stdClass'} = 0x82a3666f6fa3626172c0a8737464436c617373.

Php msgpack can't deserialized this data correctly, probably because it expects "\0": 'stdClass' to be the first item in the array, i.e.: 0x82c0a8737464436c617373a3666f6fa3626172.

So, the question, could this extension be enhanced to not depend on the position of the "\0" key?

magpack_pack下标问题

msgpack_pack(array(1007, 'code' => 400));
msgpack_pack(array(1007, 400));

当用luamsgpack.decode解码时， 会得到table{[0]=1007, ['code']=400} , {1007, 400}
因为lua数组下标从1开始，期望结果应该是 table{1007, ['code']=400}

Segfault 5.5.6

Program received signal SIGSEGV, Segmentation fault.
0x00000000006e51d9 in gc_zval_possible_root ()
(gdb) bt
#0 0x00000000006e51d9 in gc_zval_possible_root ()
#1 0x00000000006d3628 in zend_hash_destroy ()
#2 0x00000000006c482b in _zval_dtor_func ()
#3 0x00000000006b694a in _zval_ptr_dtor ()
#4 0x00007fffee000d8a in msgpack_unserialize_var_destroy (var_hashx=var_hashx@entry=0x7fffffff1170, err=err@entry=1 '\001')

at /tmp/pear/temp/msgpack/msgpack_unpack.c:331

#5 0x00007fffedffb54a in php_msgpack_unserialize (return_value=return_value@entry=0x7fffedb82178, str=, str_len=2363631)

at /tmp/pear/temp/msgpack/msgpack.c:268

#6 0x00007fffedffb66d in zif_msgpack_unserialize (ht=, return_value=0x7fffedb82178, return_value_ptr=,

this_ptr=<optimized out>, return_value_used=<optimized out>) at /tmp/pear/temp/msgpack/msgpack.c:332

#7 0x000000000076d471 in ?? ()
#8 0x00000000007272e7 in execute ()
#9 0x00000000006c714c in zend_execute_scripts ()
#10 0x0000000000666fd3 in php_execute_script ()
#11 0x000000000076fe03 in ?? ()
#12 0x0000000000431c8f in ?? ()
#13 0x00007ffff503eead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#14 0x0000000000431d25 in _start ()

No ChangeLog update since 0.5.3

Empty objects get serialized with incorrect type

The following code:

class test {} 
var_dump (msgpack_unserialize (msgpack_serialize (new test())));

Results into:

object(stdClass)#1 (0) {
}

this extension requires at least PHP version 5 or newer

Hey there,

I get this error message when enabling msgpack while building php from source. I can make it happen by simply cloning php-src from github, adding msgpack to the ext directory, and then trying to build it.

If I comment out the check in config.m4, it compiles and work great.

I'm running Ubuntu 13.10 and specifically building inside the 5.5.6 tag from php-src. That being said, I had this problem with several previous versions of PHP and Ubuntu as well.

If it helps, I'm building it like so:

./buildconf --force
./configure --enable-debug \
            --enable-redis \
            --with-curl \
            --enable-redismi \
            --with-mysqli \
            --with-zlib \
            --with-msgpack

Please let me know if I'm doing something silly. :)

Cheers,
Mike

msgpack_unpack slow

https://github.com/phadej/igbinary
Gist

msgpack_unpack [mixed] - 1.4 sec
msgpack_unpack [objects] - 4 sec

unserialize() [strings]: 1.1574549674988 time to decode
json_decode() [strings]: 2.4062461853027 time to decode
igbinary_unserialize() [strings]: 1.0055360794067 time to decode
msgpack_unpack() [strings]: 1.3539419174194 time to decode
====================
unserialize() [integers]: 1.9812541007996 time to decode
json_decode() [integers]: 2.5996360778809 time to decode
igbinary_unserialize() [integers]: 1.3478710651398 time to decode
msgpack_unpack() [integers]: 1.6021440029144 time to decode
====================
unserialize() [booleans]: 1.1899609565735 time to decode
json_decode() [booleans]: 1.918792963028 time to decode
igbinary_unserialize() [booleans]: 0.87304401397705 time to decode
msgpack_unpack() [booleans]: 1.0228171348572 time to decode
====================
unserialize() [floats]: 12.473134040833 time to decode
json_decode() [floats]: 3.6526660919189 time to decode
igbinary_unserialize() [floats]: 1.3724019527435 time to decode
msgpack_unpack() [floats]: 1.6542191505432 time to decode
====================
unserialize() [mixed]: 3.2900521755219 time to decode
json_decode() [mixed]: 2.3472380638123 time to decode
igbinary_unserialize() [mixed]: 0.90776085853577 time to decode
msgpack_unpack() [mixed]: 1.4055440425873 time to decode
====================
unserialize() [objects]: 6.0958180427551 time to decode
json_decode() [objects]: 6.070100069046 time to decode
igbinary_unserialize() [objects]: 3.5009729862213 time to decode
msgpack_unpack() [objects]: 4.7423760890961 time to decode
====================
unserialize() [all]: 26.789407968521 time to decode
json_decode() [all]: 19.630469083786 time to decode
igbinary_unserialize() [all]: 8.5214760303497 time to decode
msgpack_unpack() [all]: 12.472622871399 time to decode
====================

Use as xcopy-deployable folders?

Is there any chance to use msgpack-php without installing it through PECL?

I want to deliver my project as a standalone folder without depending on any other server configuration beside PHP being installed.

This answer on SO claims that it is possible but I want to directly ask here for your specific package.

So my question is:

(How) can I ship msgpack-php as a sub folder of my website without installing it on the server?

[PHP] From libmsgpack.a to .so

Hi,
I need to compile for powerpc platform and I need a shared object file.

If I compile using

./configure CC=powerpc-e300c3-linux-gnu-gcc --host=powerpc

I have two files:

• libmsgpack.a
• msgpack.la

How can I include this file into php?

inlining of functions causes dynamic load failure on Mac OS X

Recently, when rebuilding msgpack on OS X 10.9, the resulting module had problems performing object unpacking. The error given was:

tests/101.log:dyld: Symbol not found: _msgpack_convert_long_to_properties
tests/101.out:dyld: lazy symbol binding failed: Symbol not found: _msgpack_convert_long_to_properties

and a number of the tests would fail.

The fix seems to be to de-inline the functions in msgpack_convert.c. Since they're only referenced from that source file anyway, there's not much benefit to the inlining anyway. :)

I've included a diff of my change, and so far, it seems to be working correctly.

diff --git a/msgpack_convert.c b/msgpack_convert.c
index 29655b0..8e6c784 100644
--- a/msgpack_convert.c
+++ b/msgpack_convert.c
@@ -34,7 +34,7 @@
return SUCCESS;
}

-inline int msgpack_convert_long_to_properties(
+int msgpack_convert_long_to_properties(
HashTable _ht, HashTable *_properties, HashPosition *prop_pos,
uint key_index, zval *val, HashTable *var)
{
@@ -133,7 +133,7 @@ inline int msgpack_convert_long_to_properties(
return zend_hash_index_update(ht, key_index, &val, sizeof(val), NULL);
}

-inline int msgpack_convert_string_to_properties(
+int msgpack_convert_string_to_properties(
zval _object, char *key, uint key_len, zval *val, HashTable *var)
{
zval *_data = NULL;
diff --git a/msgpack_convert.h b/msgpack_convert.h
index 93e045e..2f2f5a9 100644
--- a/msgpack_convert.h
+++ b/msgpack_convert.h
@@ -2,8 +2,10 @@
#ifndef MSGPACK_CONVERT_H
#define MSGPACK_CONVERT_H

-int msgpack_convert_object(zval _return_value, zval *object, zval *_value);
-int msgpack_convert_array(zval _return_value, zval *tpl, zval *_value);

-int msgpack_convert_template(zval _return_value, zval *tpl, zval *_value);

+extern int msgpack_convert_object(zval _return_value, zval *object, zval *_valu
+extern int msgpack_convert_array(zval _return_value, zval *tpl, zval *_value);
+extern int msgpack_convert_template(zval _return_value, zval *tpl, zval *_value
+extern int msgpack_convert_long_to_properties(HashTable _ht, HashTable *_proper

• uint key_index, zval *val, HashTable *var);
• #endif

msgpack_unpack() failed to unpack data

Hello, I use msgpack-c 1.0 to pack the following string:
{"code":20004,"ex":"Unknow method","msg":"Socket: 5, address: 127.0.0.1:49120","raiser":"setasdf"}

my result is 82 bytes(hex):
84a4636f6465cd4e24a26578ad556e6b6e6f77206d6574686f64a36d7367d923536f636b65743a20352c20616464726573733a203132372e302e302e313a3439313230a6726169736572a773657461736466

Then I use msgpack-php to unpack it, but it failed:
PHP Warning: msgpack Parse error ...

I guess it's because msgpack-c 1.0 pack data according to spec v5, but msgpack-php still not support spec v5. But I'm not sure this was the case. Or if it is true, is there any plan for msgpack-php to support spec v5?

Thank you.

Invalid write reported by valgrind

warning message show when run tests/040*.phpt with valgrind.

but it's not critical, only comes up in wrong usage, so I leave it here.

$ cat tests/040.mem
==13658== Invalid read of size 4
==13658== at 0x802623: _zval_ptr_dtor (zend.h:391)
==13658== by 0x817DA5: _zval_ptr_dtor_wrapper (zend_variables.c:182)
==13658== by 0x8308D2: zend_hash_destroy (zend_hash.c:560)
==13658== by 0x81795B: _zval_dtor_func (zend_variables.c:45)
==13658== by 0x8026E3: _zval_ptr_dtor (zend_variables.h:35)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== Address 0x56bdb80 is 16 bytes inside a block of size 32 free'd
==13658== at 0x4A07384: free (vg_replace_malloc.c:427)
==13658== by 0x7D6E25: _efree (zend_alloc.c:2433)
==13658== by 0x802701: _zval_ptr_dtor (zend_execute_API.c:439)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== by 0x762A5A: php_execute_script (main.c:2482)
==13658== by 0x99E1DD: do_cli (php_cli.c:988)
==13658==
==13658== Invalid write of size 4
==13658== at 0x80262D: _zval_ptr_dtor (zend.h:391)
==13658== by 0x817DA5: _zval_ptr_dtor_wrapper (zend_variables.c:182)
==13658== by 0x8308D2: zend_hash_destroy (zend_hash.c:560)
==13658== by 0x81795B: _zval_dtor_func (zend_variables.c:45)
==13658== by 0x8026E3: _zval_ptr_dtor (zend_variables.h:35)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== Address 0x56bdb80 is 16 bytes inside a block of size 32 free'd
==13658== at 0x4A07384: free (vg_replace_malloc.c:427)
==13658== by 0x7D6E25: _efree (zend_alloc.c:2433)
==13658== by 0x802701: _zval_ptr_dtor (zend_execute_API.c:439)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== by 0x762A5A: php_execute_script (main.c:2482)
==13658== by 0x99E1DD: do_cli (php_cli.c:988)
==13658==
==13658== Invalid read of size 4
==13658== at 0x80263F: _zval_ptr_dtor (zend.h:379)
==13658== by 0x817DA5: _zval_ptr_dtor_wrapper (zend_variables.c:182)
==13658== by 0x8308D2: zend_hash_destroy (zend_hash.c:560)
==13658== by 0x81795B: _zval_dtor_func (zend_variables.c:45)
==13658== by 0x8026E3: _zval_ptr_dtor (zend_variables.h:35)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== Address 0x56bdb80 is 16 bytes inside a block of size 32 free'd
==13658== at 0x4A07384: free (vg_replace_malloc.c:427)
==13658== by 0x7D6E25: _efree (zend_alloc.c:2433)
==13658== by 0x802701: _zval_ptr_dtor (zend_execute_API.c:439)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== by 0x762A5A: php_execute_script (main.c:2482)
==13658== by 0x99E1DD: do_cli (php_cli.c:988)
==13658==
==13658== Invalid read of size 4
==13658== at 0x802726: _zval_ptr_dtor (zend.h:379)
==13658== by 0x817DA5: _zval_ptr_dtor_wrapper (zend_variables.c:182)
==13658== by 0x8308D2: zend_hash_destroy (zend_hash.c:560)
==13658== by 0x81795B: _zval_dtor_func (zend_variables.c:45)
==13658== by 0x8026E3: _zval_ptr_dtor (zend_variables.h:35)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== Address 0x56bdb80 is 16 bytes inside a block of size 32 free'd
==13658== at 0x4A07384: free (vg_replace_malloc.c:427)
==13658== by 0x7D6E25: _efree (zend_alloc.c:2433)
==13658== by 0x802701: _zval_ptr_dtor (zend_execute_API.c:439)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== by 0x762A5A: php_execute_script (main.c:2482)
==13658== by 0x99E1DD: do_cli (php_cli.c:988)
==13658==
==13658== Invalid read of size 1
==13658== at 0x802758: _zval_ptr_dtor (zend_gc.h:182)
==13658== by 0x817DA5: _zval_ptr_dtor_wrapper (zend_variables.c:182)
==13658== by 0x8308D2: zend_hash_destroy (zend_hash.c:560)
==13658== by 0x81795B: _zval_dtor_func (zend_variables.c:45)
==13658== by 0x8026E3: _zval_ptr_dtor (zend_variables.h:35)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== Address 0x56bdb84 is 20 bytes inside a block of size 32 free'd
==13658== at 0x4A07384: free (vg_replace_malloc.c:427)
==13658== by 0x7D6E25: _efree (zend_alloc.c:2433)
==13658== by 0x802701: _zval_ptr_dtor (zend_execute_API.c:439)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== by 0x762A5A: php_execute_script (main.c:2482)
==13658== by 0x99E1DD: do_cli (php_cli.c:988)
==13658==
==13658== Invalid read of size 1
==13658== at 0x802764: _zval_ptr_dtor (zend_gc.h:182)
==13658== by 0x817DA5: _zval_ptr_dtor_wrapper (zend_variables.c:182)
==13658== by 0x8308D2: zend_hash_destroy (zend_hash.c:560)
==13658== by 0x81795B: _zval_dtor_func (zend_variables.c:45)
==13658== by 0x8026E3: _zval_ptr_dtor (zend_variables.h:35)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== Address 0x56bdb84 is 20 bytes inside a block of size 32 free'd
==13658== at 0x4A07384: free (vg_replace_malloc.c:427)
==13658== by 0x7D6E25: _efree (zend_alloc.c:2433)
==13658== by 0x802701: _zval_ptr_dtor (zend_execute_API.c:439)
==13658== by 0x502E623: msgpack_unserialize_var_destroy (msgpack_unpack.c:331)
==13658== by 0x502971C: php_msgpack_unserialize (msgpack.c:274)
==13658== by 0x50299E6: zif_msgpack_unserialize (msgpack.c:332)
==13658== by 0x863081: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642)
==13658== by 0x86C5F4: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2235)
==13658== by 0x860D97: execute (zend_vm_execute.h:410)
==13658== by 0x81CFDB: zend_execute_scripts (zend.c:1309)
==13658== by 0x762A5A: php_execute_script (main.c:2482)
==13658== by 0x99E1DD: do_cli (php_cli.c:988)
==13658==

Release a new version to support msgpack 2.0

The latest version 0.5.6 released in the http://pcel.php.net has no support for msgpack 2.0 which has been supported (or partial?) by the master branch. I think it would be a convenience to deploy a new version to the http://pcel.php.net.

Thanks.