Pocketmine-mp: Random php exit 127 on Windows 64-bit/segfault on Linux

[L3ice]

Issue description

Using the default setting of async-workers(auto) ends in an Error:
bin\php\php.exe: Exit 127

Steps to reproduce the issue

1. set async-workers in pocketmine.yml to auto
2. Start the server

OS and versions

• PocketMine-MP: https://github.com/pmmp/PocketMine-MP/commit/074583d104f1f92d47505355bf90e3d1d455fef7
• PHP: 7.0.3
• Server OS: Windows 10(1607) 64 Bit
• Game version: -

Crashdump, backtrace or other files

*
http://pastebin.com/AMxMqjL6

[dktapps]

Are you certain this is caused by this setting? Try to reproduce it a few times?

[L3ice]

I tried it several times.
Using 1 or 2 before and then set it back to auto.

[knownunown]

Looks fine on my end using 074583d104f1f92d47505355bf90e3d1d455fef7. Tested in two environments: Windows 10 Pro 14951 & (official) PHP 7.0.3, MacOS 10.12.1 & (non-standard) PHP 7.0.12.

[L3ice]

Interesting.
Using the number of cores I have(4), gives the same error.
So it detects my cores correctly.
So it must be something different.
I did not test it with 4 yesterday, because I didn't know how many cores I have.

[dktapps]

Reproduced on Windows 10 Home 64-bit 14393.531 with php 7.0.12 x64, circumstances unknown. First try this happened, second time it started up fine.

[L3ice]

I did run it now from source and it also happend only at the first start with php 7.0.3 x64.

[dktapps]

This points to a recursive function call. While the observed random exit 127 (and on Linux, random segmentation fault) is a pthreads bug, as it should yield an out of memory error, this points to an issue within the PocketMine core itself.

[KAGsundaram]

" First try this happened, second time it started up fine." - dktapps

Exactly what I saw the first two times I started PocketMine-MP_1.6.1dev-73_794ff643_API-2.1.0.

However, I have loaded half a dozen different Pocketmine forks in the past three days, and I have seen this randomly occurring exit 127 in all of them.

It is NOT running out of physical memory; I have the system monitor constantly displayed, only 57% max of my 8GB is in use.

[KAGsundaram]

Quoting Avdi in Ruby Tapas - Episode #385 - Error 127:

"AHA! It turns out, 127 is a standard shell command exit status value, and it means “command not found”. "

https://www.rubytapas.com/2016/02/22/episode-385-error-127/

[dktapps]

Program received signal SIGSEGV, Segmentation fault.
malloc_consolidate (av=av@entry=0x7ffff650e760 <main_arena>)
    at malloc.c:4149
4149              size = p->size & ~(PREV_INUSE|NON_MAIN_ARENA);
(gdb) bt
#0  malloc_consolidate (av=av@entry=0x7ffff650e760 <main_arena>)
    at malloc.c:4149
#1  0x00007ffff61d1ea5 in _int_malloc (
    av=av@entry=0x7ffff650e760 <main_arena>, bytes=bytes@entry=16384)
    at malloc.c:3443
#2  0x00007ffff61d38dc in __GI___libc_malloc (bytes=16384)
    at malloc.c:2895
#3  0x00007ffff7773251 in yaml_parser_initialize ()
   from /home/dktapps/test/bundle/bin/php7/bin/../lib/libyaml-0.so.2
#4  0x00000000007109ed in ?? ()
#5  0x00007fffffffa510 in ?? ()
#6  0x00007fffca6ee398 in ?? ()
#7  0x0000000000000000 in ?? ()
(gdb)

From a CentOS server (x64) php 7.0.12

[robske110]

Yaml?!

[dktapps]

I'm seeing config-related segfaults like this very frequently, yes. It appears to be an extension issue as opposed to a core bug.

[jduncanator]

Appears to be failing here, not quite sure why yet, but to me it seems like a libc bug, rather than a yaml, PHP or PocketMine bug.

Another potential cause may be heap trashing by another piece of code that results in a malloc segfault, but I'm surprised it _always_ fails in the same place.

[Tolo0]

Any solution?

[Tolo0]

Problem maybe solved. thanks to SalmonGER for the advice
pocketmine.yml / async-workers fault.
pocketmine cant use more than 4 cores so if ur dedicated server has more than 4 and u have async-workers set to auto. You will get segmentation fault.

#Set this approximately to your number of cores.

#If set to auto, it'll try to detect the number of cores (or use 2)
async-workers: 4

[dktapps]

Actually, if you look at https://travis-ci.org/pmmp/PocketMine-MP/builds/198337842, you'll see that in Travis at least it can use 32 cores...

[Tolo0]

its not a fix its just a temporary solution. it worked for me so im sure it will help others. i have no knowledge with coding but it could be something to do with the async-workers part of code. my dedicated server has 8 cores but pocketmine doesnt let me use all 8. only 4 max so i don't know how anyone would use 32. maybe its worth looking into.

[jduncanator]

I've got a little more info on this one since December.

Running Valgrind over the php binary running PocketMine throws a whole swathe of issues out, which could point to a bigger issue. I haven't had time to sort through the issues reported, but when I do, I'll report back here.

[dktapps]

I haven't had time to investigate this myself... but there is one annoying segfault that almost _always_ occurs on shutdown on Travis.

[LeronHinds]

I had this problem today, all I had to do was update my php binaries for pocketmine. I was using PHP 7.0.3 and updated to 7.0.18 and everything seems to be working now.

[dktapps]

The issues described in this issue are due to ZTS issues in PHP 7.0 and 7.1. We'll be upgrading to PHP 7.2 as soon as possible. PHP 7.2 fixes a wide range of stability issues such as this.

Since this is a PHP issue and not PocketMine, I'm going to close this.