Error while running LongPoll example in OSX snowleopard

[ace88sg]

Core_Worker_Mediator::shm_init Failed. Could Not Read Header. If this problem persists, try running the daemon with the --resetworkers option

tried with the --resetworkers option

php run.php --resetworkers

but the error still persists ...

Any idea how it can be resolved? Its running PHP5.4.8

Thanks

[ace88sg]

Just checked my shared memory functions - They are all working shm_attach, shm_get_var, shm_put_var, shm_remove, shm_has_var

FYI

[ace88sg]

Mediator.php

• failing at function ipc_create()
• shm_attach failed to create any shared memory
• inputs into the function call are
• $this->id was 1090653144
• $this->memory_allocation was 5242880

$this->shm = shm_attach($this->id, $this->memory_allocation, 0666);

return value from shm_attach was 0

[ace88sg]

This was the part that gave the error shm_has_var($this->shm, self::HEADER_ADDRESS) returned false $this->shm was 0 self::HEADER_ADDRESS was 1

Hope this makes sense of my situation ...

    // Write a header to the shared memory block
    if (!shm_has_var($this->shm, self::HEADER_ADDRESS)) {
        $header = array(
            'version' => self::VERSION,
            'memory_allocation' => $this->memory_allocation,
        );

        if (!shm_put_var($this->shm, self::HEADER_ADDRESS, $header))
            throw new Exception(__METHOD__ . " Failed. Could Not Read Header. If this problem persists, try running the daemon with the --resetworkers option.");
    }

[shaneharter]

Just checked my shared memory functions - They are all working

Just curious how you verified this?

If shm_attach is returning 0 it's an indication that PHP could not attach that memory address.

In the /scripts directory, run: $ php shm_console.php

In the console, paste in the ID 1090653144 you listed above. Then run "scan" to see if any data has been written to that address. Most likely there will not be, but I'm curious if the shm_console can attach the address.

In any event, the next step I would do is to manually remove that memory address. You can use this using a binary from the commandline:

ipcrm -m 0x41020BD8

(0x41020BD8 is the hex value of 1090653144. You're telling it to remove that memory block).

The clean_ipc.php script in /scripts does this for you but it could also remove shared memory that may be set by another app. Best in this case to just remove the specific block.

[shaneharter]

Also, can you run the PrimeNumbers example? Does that work?

[ace88sg]

Thanks for helping out bro ...

Today's id was 1090658080 memory_allocation was the same at 5242880

Difference today is $this-shm returned 19 then 0 during the 1st and 2nd call of ipc_create() when I ran the LongPoll example, before shutting down

I did a printf on the $this->shm INTEGER just after the shm_attach

---

protected function ipc_create() { $this->shm = shm_attach($this->id, $this->memory_allocation, 0666); if (shm_has_var($this->shm,$this->id)) { printf("shm created OK %d id %d mem %d \n",$this->shm,$this->id,$this->memory_allocation); } else { printf("shm created notOK %d id %d mem %d \n",$this->shm,$this->id,$this->memory_allocation);

}

....}

---

shm created notOK 19 id 1090658080 mem 5242880 shm created notOK 0 id 1090658080 mem 5242880

Date PID Label Message [2012-12-17 16:57:45] 301 Core_Worker_Mediator::shm_init Failed. Could Not Read Header. If this problem persists, try running the daemon with the --resetworkers option. [2012-12-17 16:57:45] 301 Examples\LongPoll\Poller is Shutting Down...

---

this was the result for the scan. I ran that after running the LongPoll example in another shell terminal while keeping the shell terminal that ran LongPoll open.

---

macmini:scripts ace88sg$ sudo php shm_console.php

PHP Simple Daemon - Shared Memory Console Enter Shared Memory Address or Select a Shortcut: [-0] PrimeNumbers 1342185173 [-1] GetFactors 1191190231 [-2] LongPoll_API 1090519102

Hint: To determine the address used by a worker, send a 10 signal to your daemon. It will be a 10 digit number beside the worker's alias

ADDR > 1090658080 Address 1090658080 Attached Note: This shared memory address appears uninitilized: No header has been written.

ID >

---

I verified shared memory functions by running a short script I found on the internet. it seemed to work ok ... hence I assumed shared memory was ok to use

---

<?php //Check the command line arguments if(sizeof($argv) < 2) { echo "Usage: php shared_memory.php \n"; exit; }

//Define shared memory segment properties. $key = "987654"; $permissions = 0666; $size = 1024;

//Create or open the shared memory segment. $segment = shm_attach($key, $size, $permissions);

//Handle operations for the segment. switch($argv[1]) { case "send": shm_put_var($segment, $argv[2], $argv[3]); echo "Message sent to shared memory segment.\n"; break; case "get": $data = shm_get_var($segment, $argv[2]); echo "Received data: {$data}\n"; break; case "delete": shm_remove($segment); echo "Shared memory segment released.\n"; break; }

?>

---

pasted script into shm.php -- sudo php shm.php Usage: php shared_memory.php send|get|delete integer identifier value

-- sudo php shm.php send 12345 "this is a test" Message sent to shared memory segment.

-- sudo php shm.php get 12345 Received data: this is a test

-- sudo php shm.php delete Shared memory segment released.

[ace88sg]

Output for Prime Numbers - Memory SCAN said NULL

macmini:PrimeNumbers ace88sg$ sudo php run.php Password: shm created notOK 0 id 1342316899 mem 31457280 shm created notOK 0 id 1342316899 mem 31457280 shm created notOK 0 id 1342316899 mem 31457280 shm created notOK 0 id 1342316899 mem 31457280 shm created notOK 0 id 1342316899 mem 31457280 shm created notOK 0 id 1342316899 mem 31457280

Date PID Label Message [2012-12-17 17:26:44] 320 Core_Worker_Mediator::shm_init Failed. Could Not Read Header. If this problem persists, try running the daemon with the --resetworkers option. [2012-12-17 17:26:44] 320 Examples\PrimeNumbers\Daemon is Shutting Down...

[2012-12-17 17:26:44] 325 PrimeNumbers Worker Process Started [2012-12-17 17:26:44] 322 PrimeNumbers Worker Process Started [2012-12-17 17:26:44] 322 Exception Caught in Fork: Core_Worker_Mediator::setup Failed. Could not address shared memory block 1342316899 [2012-12-17 17:26:44] 325 Exception Caught in Fork: Core_Worker_Mediator::setup Failed. Could not address shared memory block 1342316899 [2012-12-17 17:26:44] 324 PrimeNumbers Worker Process Started [2012-12-17 17:26:44] 323 PrimeNumbers Worker Process Started [2012-12-17 17:26:44] 324 Exception Caught in Fork: Core_Worker_Mediator::setup Failed. Could not address shared memory block 1342316899 [2012-12-17 17:26:44] 323 Exception Caught in Fork: Core_Worker_Mediator::setup Failed. Could not address shared memory block 1342316899

---

Memory SCAN ID > 1342316899 Shared Memory Contents: Null ID >

[shaneharter]

No problem -- sorry you're having trouble.

The shared memory extension in PHP isn't the most widely used as you can imagine. So it's possible, being on OSX instead of Linux/BSD, that you're experiencing some bug or edge-case in the extension that I wasn't aware of.

I develop on a MBP but I use a Ubuntu VM for testing this project. I can try it out on OSX tonight (Lion in my case) and see if I have any luck.

The --resetworkers flag actually isn't doing anything. I'll fix that error message. I used to leave SHM resources attached when your application exits, and re-connect to them when you start it up again. That way you could, in theory, pick up where you left off. But that model proved unreliable, so I instead moved to a scheme where it always releases SHM resources unless you pass --recoverworkers. When you pass that flag, it will attempt to re-connect and pick up where you left off.

None of that is helpful for you but I just wanted you to know that the resetworkers flag is not used any longer. I refactored all the code that uses it but must have missed the text in that error message.

So, moving forward:

Checkout the feature_abstractipc branch and see if you can run the primenumbers example in that. It's the "2.1" development branch. It's stable-ish. I wouldn't deploy that code yet but it's getting close to a real beta test.

You'll see a lot of backend changes to the Worker code in that branch. I've put all the SHM-specific code in Worker/Via/Shm.php. The plan here is to build additional Via objects (using other IPC methods like protobufs, named pipes, external queues like Beanstalkd, Kestrel, etc) so you can chose the IPC method that works best for your app.

Anyway, I know this comment isn't that helpful. But I am curious if the code works in the abstractipc branch. I'll play around on my end and see if I can reproduce the bug on my OSX box.

[ace88sg]

Thanks for keeping OSX in view ...

Ran the abstract_ipc version of the code but it returned nothing. No errors though ... hope this helps

macmini:LongPoll ace88sg$ sudo php run.php macmini:LongPoll ace88sg$

[shaneharter]

If you don't mind, try the prime numbers example on that branch. I haven't updated the long poll example to use the new API yet.

On Monday, December 17, 2012, ace88sg wrote:

Thanks for keeping OSX in view ...

Ran the abstract_ipc version of the code but it returned nothing. No errors though ... hope this helps

macmini:LongPoll ace88sg$ sudo php run.php macmini:LongPoll ace88sg$

— Reply to this email directly or view it on GitHubhttps://github.com/shaneharter/PHP-Daemon/issues/21#issuecomment-11471775.

[vincentpazeller]

Hello,

I am starting with your library (v2.0), find it very interesting. I am having a very similar issue on MacOS X. I have made a small test script to test that shared memory is actually available and working (and it is). The Tasks example is working but not the two others... I have tested the examples on another server (debian) and here the LongPoll example seems to work. I was wondering whether there was any progress there...

Thank you

[dmertl]

I believe this is a problem with the shared memory size. The size being allocated via shm_attach is above the Mac OS X limit. I dropped the malloc size down and was able to get it to run.