search

derickr / vld

BSD 2-Clause "Simplified" License
467 stars 89 forks source link

Segfault in vld_set_add #23

Closed neerolyte closed 9 years ago

neerolyte commented 9 years ago

I've installed from source directly and I'm getting segfaults with some scripts (I was also getting segfaults with the version in pecl, I think this is the same segfault).

I've grabbed a backtrace with gdb by running the script with:

root@vagrant-ubuntu-trusty-64:~# gdb -q -ex "set args -dvld.active=1 -dvld.execute=0 -f foo.php" -ex run php

Ignoring most of the gdb output, I note that vld does manage some output:

Finding entry points
Branch analysis from position: 0
Jump found. Position 1 = -1953155152
Branch analysis from position: -1953155152

Then:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffed5ad4b5 in vld_set_add (set=0x1229440, position=position@entry=2341812144) at /vagrant/vld/set.c:44
warning: Source file is more recent than executable.
44              *byte = *byte | 1 << bit;

note: the warning about the Source file being more recent just seems to be some odd clock skew thing on this VM... I don't think it's relevant.

and the actual backtrace:

(gdb) bt
#0  0x00007fffed5ad4b5 in vld_set_add (set=0x1229440, position=position@entry=2341812144) at /vagrant/vld/set.c:44
#1  0x00007fffed5acc52 in vld_analyse_branch (opa=opa@entry=0x7ffff7e18390, position=2341812144, set=set@entry=0x12b3d50, 
    branch_info=branch_info@entry=0x12733d0) at /vagrant/vld/srm_oparray.c:1013
#2  0x00007fffed5acfaa in vld_analyse_branch (opa=opa@entry=0x7ffff7e18390, position=52, position@entry=0, set=set@entry=0x12b3d50, 
    branch_info=branch_info@entry=0x12733d0) at /vagrant/vld/srm_oparray.c:1038
#3  0x00007fffed5ad032 in vld_analyse_oparray (opa=opa@entry=0x7ffff7e18390, set=set@entry=0x12b3d50, 
    branch_info=branch_info@entry=0x12733d0) at /vagrant/vld/srm_oparray.c:983
#4  0x00007fffed5ad420 in vld_dump_oparray (opa=opa@entry=0x7ffff7e18390) at /vagrant/vld/srm_oparray.c:820
#5  0x00007fffed5ab104 in vld_compile_file (file_handle=<optimized out>, type=<optimized out>) at /vagrant/vld/vld.c:379
#6  0x00000000006ef95f in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3)
    at /build/php5-iwKH5X/php5-5.5.9+dfsg/Zend/zend.c:1308
#7  0x000000000068f805 in php_execute_script (primary_file=primary_file@entry=0x7fffffffd120)
    at /build/php5-iwKH5X/php5-5.5.9+dfsg/main/main.c:2506
#8  0x00000000007a008e in do_cli (argc=5, argv=0xebeb70) at /build/php5-iwKH5X/php5-5.5.9+dfsg/sapi/cli/php_cli.c:994
#9  0x0000000000461d90 in main (argc=5, argv=0xebeb70) at /build/php5-iwKH5X/php5-5.5.9+dfsg/sapi/cli/php_cli.c:1378

The file in questions has been encoded with IonCube (I don't know which version), I can't share the file. I tried encoding a collection of random source php with the trial version of the IonCube encoder and they all produced opcodes just fine.

I'm using the current default PHP in Ubuntu 14.04: 5.5.9-1ubuntu4.13.

I'm not really sure what else to try at this point as I'm only a little familiar with C/gdb and as such understanding what's gone wrong enough to make any kind of intelligent source change is beyond me at the moment - I'm happy to try out other debugging options if there's something I've missed that might help diagnose the problem.

derickr commented 9 years ago

Hi!

Thanks for reporting this. But without a file, I can't fix this. VLD's branch analysis is so tricky that there is just no way for me to debug/find this without the original file.

cheers, Derick

neerolyte commented 9 years ago

No worries, I expected this, I was just hopeful there'd be some neat thing I could ask GDB that'd give you an important insight.

Cheers, Dave