Skip to content
This repository has been archived by the owner on Dec 16, 2019. It is now read-only.

PHP Segmentation fault at start #54

Closed
shoghicp opened this issue Jan 22, 2013 · 12 comments
Closed

PHP Segmentation fault at start #54

shoghicp opened this issue Jan 22, 2013 · 12 comments

Comments

@shoghicp
Copy link

Some users are notifyng me that PHP 5.4.11 crashes before executing any code, happening on Windows, and to only one on Linux.

I don't have any more details though, because these users only tweeted me. I talked with one of them to check if my code was executed, but a simple "echo 1;" failed. Also tested disabling the pthreads extension on Windows, and the code executed.

Thanks!

@krakjoe
Copy link
Owner

krakjoe commented Jan 22, 2013

I am in the middle of a few changes to reduce consumption, amongst other things. As it stands the code in git is leaky and has errors, it won't be like this for long I just didn't get a chance to finish today .... if you could keep an eye on my commit comments, I shall note when I consider it stable again ...

Sorry I know this is a pain in the ass, but necessary before the next release can be prepared. The niggling problems were piling up to an unacceptable level, it should be worth the effort, the pooling example runs on my machine ( a core i7 ) under 5.4 in 0.007 seconds when php is built without debug symbols ...

To provide some comfort, I have reduced consumption by removing the reliance on default properties, we never write the default properties table anymore, slashing our consumption by a wide margin depending on the task,in theory always at least 100% improvement, the more complicated the code ( the more objects and contexts you create ) the more you save.
I have removed what pthreads called the object cache which was a solution to keeping refcounts properly being that our data store doesn't use or store zvals - the reason this was removed is that during the execution of a worker, consumption would rise until the worker is shutdown, because all references to stackables were kept throughout execution, this is no longer so, once the threading context is done with a stackable it's reference is free'd ( in the threading context ) before the next stackable is executed.
As much as possible, I have removed references to EG() in the threading context, as this incurs locking on every call, when a thread needs to manipulate it's executor globals it is the only thread doing so, so incurring the lock is pointless.

Again sorry for the inconvenience ...

PS. I will investigate this particular problem, I'd be grateful if you could tell your users and twitter friends what I just said ( somehow, in the 160 chars you get on twitter ), it won't be long before everything is much better than normal ... additionally, I will ask the pecl windows guy if I should compile releases and windows snapshots against the latest version of PHP, I think probably a binary incompatibility has been introduced by this last version.

@chibisuke
Copy link
Contributor

Well you can always use a previous version.

jugeing from the commit messages most revisions before cbb0cb0 should be "stable" to use.

@krakjoe Maybe it would be beneficial to have a "stable" branch in the repo that you update only when you're sure there isn't much breaking stuff in it anymore. Something people can checkout that don't want to wait for releases, but on the other hand don't want to bother to much with the instabilities of bloody edge development.

@shoghicp
Copy link
Author

The actual Linux autoinstaller (in my project) uses the latest master commit to compile against the latest PHP (note: this issue has been notified using PHP 5.4.10, and .11).

@krakjoe
Copy link
Owner

krakjoe commented Jan 23, 2013

You should be good to go with the last commit ... snaps available for windows ...

It's 2am, I'm knackered, I'll check back/update/comment in the morning ...

@shoghicp
Copy link
Author

Thanks!

But the latest build crashes now every time, even on my computer

@krakjoe
Copy link
Owner

krakjoe commented Jan 23, 2013

Are you using windows ? If you're using linux/mac, did you make clean ??

@chibisuke, what about you are your builds working ??

EDIT: 01ceeac try that ??? ( snaps available )

@shoghicp
Copy link
Author

Properties doesn't get loaded.

class ConsoleLoop extends Thread{ var $line = false, $stop = false; public function run(){ $fp = fopen("php://stdin", "r"); var_dump($this->stop); //NULL while($this->stop === false and ($line = fgets($fp)) !== false){ $this->line = $line; $this->wait(); $this->line = false; } exit(0); } }

The Thread will exit, and the var_dump($this->stop) prints "NULL"

@krakjoe
Copy link
Owner

krakjoe commented Jan 23, 2013

<?php
class ConsoleLoop extends Thread{
    public $line;
    public $stop;

    public function __construct(){
        $this->line = null;
        $this->stop = false;
    }

    public function run(){
        $fp = fopen("php://stdin", "r");
        while($this->stop === false and ($line = fgets($fp)) !== false){
            $this->line = $line;
            $this->wait();
            $this->line = false;
        }
        exit(0);
    }
}
?>

We no longer use the default PHP properties, there's very good reason for this. Imagine you have a worker executing 100 stackables, if you declare defaults the PHP way at the class level, those defaults will be copied for every stackable, even though they will not be read from the default PHP properties ( because it's unsafe and unsupported ).

Above is how you need to do things, you should declare the properties in the normal way, but you should set the defaults in the constructor - this is the only way to invoke pthreads and make sure the data is not duplicated on every instance initialization.

@krakjoe krakjoe closed this as completed Jan 23, 2013
@shoghicp
Copy link
Author

Oh, now it works. I'll have to try this with the "test" user

@krakjoe
Copy link
Owner

krakjoe commented Jan 23, 2013

here's another idea for you, I meant to mention this last night ...

rather than using the master commit, store a file on your server, or in git that contains the id of the last stable commit, you can change this as you follow progress so that your users are not affected when code in git is unstable.

I understand wanting to use the latest version, and I understand branches too, but across all the versions of PHP pthreads works with and all the operating systems I test on, development is fragmented enough, it's as much as I can do to maintain compatibility, having multiple branches would only make that job harder, so sometimes the code in git will be unstable or have known problems ...

@shoghicp
Copy link
Author

Did that ;)

shoghicp/PocketMine-MP@237ad4e...fde7b5a

@krakjoe
Copy link
Owner

krakjoe commented Jan 23, 2013

Excellent, that'll do the trick :)

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants