Bug #74120 [Com]: SyncEvent fires only when someone is waiting

Edit report at https://bugs.php.net/bug.php?id=74120&edit=1 ID: 74120 Comment by: amancio at prjc dot com dot br Reported by: amancio at prjc dot com dot br Summary: SyncEvent fires only when someone is waiting Status: Assigned Type: Bug Package: PECL Operating System: Linux PHP Version: 5.6.30 Assigned To: cubic Block user comment: N Private report: N New Comment: When I run manually the 014.phpt, it runs without error, printing the same result as expected. I don't know why it fails when I run with 'pecl run-tests'. But the 016.phpt, it fails calling SyncSharedMemory->first(). All three calls return false, even after I remove the /dev/shm/Sync_SharedMem-* file. Arch Linux, kernel 4.8.13-1-ARCH. Previous Comments: ------------------------------------------------------------------------ [2017-02-19 21:16:52] amancio at prjc dot com dot br Hi Thomas, thank you for spending your time on this! This time I did more extensive tests to get better details about the problem. I tested on 3 different Linux boxes: * An Arch Linux, kernel 4.8.13-1-ARCH, apache 2.4.25, PHP 5.6.30; * A CentOS 7.2.1511, kernel 3.10.0-327.36.3.el7.x86_64, apache 2.4.6, PHP 5.4.16; * A CentOS 6.6, kernel 2.6.32-504.8.1.el6.x86_64, apache 2.2.15, PHP 5.3.3; I slightly changed the test script to make two of it: // Test script A $event = new SyncEvent("Test-123", true); var_dump($event->wait(0)); // pay attention here var_dump($event->fire()); var_dump($event->wait(0)); var_dump($event->reset()); // Test script B $event = new SyncEvent("Test-123", true); var_dump($event->wait(1)); // you can put any number > 0 here var_dump($event->fire()); var_dump($event->wait(0)); var_dump($event->reset()); In any Linux box, the first (clean) run of any script creates a /dev/shm/Sync_Event-* file with 0666 permission. The first run of test script A always works: it prints bool(false) bool(true) bool(true) bool(true). And in all cases, test script B always fails: it prints bool(false) bool(true) bool(false) bool(true). In both CentOS boxes, new executions of script A always work, but script B never works. Even alternating the order of execution doesn't change this result. But in Arch Linux, a simple run of script B breaks something. Any subsequent run of script A prints bool(false) bool(true) bool(false) bool(true), until I manually remove the /dev/shm/Sync_Event-* file. I ran the tests as you suggested. In both CentOS, all 16 tests passed, but in Arch two tests failed: FAIL [14/16] SyncReaderWriter - named reader-writer allocation, locking, and unlocking freeze test.[/usr/share/php56/pear/test/sync/tests/014.phpt] FAIL [16/16] SyncSharedMemory - named shared memory allocation reuse test.[/usr/share/php56/pear/test/sync/tests/016.phpt] 2 FAILED TESTS: /usr/share/php56/pear/test/sync/tests/014.phpt /usr/share/php56/pear/test/sync/tests/016.phpt If you need more information, I am willing to help. ------------------------------------------------------------------------ [2017-02-18 03:11:18] cubic@php.net I am unable to replicate the problem on Ubuntu Linux. However, after staring at the logic for a while, I did find two semi-related bugs with the underlying event object implementation. But neither bug should have triggered in a truly isolated setup. It would help me to know what var_dump($event->fire()) returns. Useful tip: var_dump() is frequently easier than writing if/else logic. What flavor of Linux are you running? There are subtle differences in POSIX implementations across even the most common Linux distros. Does the object exist in /dev/shm/? What permissions does it have (should be 0666)? If you delete the object manually, does the test start working as expected? Also of note: ext/sync/tests/011.phpt runs named manual event objects through its paces as best as a single process can test them. You should run the test suite to see if there are other object types broken on your platform. This command should work: pecl run-tests -p sync ------------------------------------------------------------------------ [2017-02-17 15:38:27] cubic@php.net Thanks for the bug report and test case. Looks like a probable regression in manual reset event objects. I'll look into this. Note that any bugs in the PECL package will almost always reflect over here: https://github.com/cubiclesoft/cross-platform-cpp Version 1.1.0 represents a major rewrite to bypass POSIX semaphore issues on some platforms (e.g. Mac) and added support for PHP 7. Windows saw no significant changes other than PHP 7 support. That at least explains why any regressions took place. ------------------------------------------------------------------------ [2017-02-17 13:58:25] amancio at prjc dot com dot br Description: ------------ Using package 'sync' PECL extension; When an instance of SyncEvent calls fire() in a thread, the other instance of SyncEvent just gets fired if it is executing wait(). If the thread is processing other things, the next call to wait() will wait indefinitely. This bad behaviour was observed just on Linux with sync 1.1.0. On Windows, sync 1.1.0 behaves correctly (the next call to wait() knows the event was already fired). Sync 1.0.1 (the previous version) behaves correctly on both platforms, Windows and Linux. Test script: --------------- // a single-threaded example: $event = new SyncEvent("Test-123", true); $event->fire(); if ($event->wait(0)) echo "Fired, ok"; else echo "Not fired?"; Expected result: ---------------- On any platform, any version should have to print "Fired, ok". Actual result: -------------- On Windows, Sync 1.0.1 and 1.1.0 prints "Fired, ok". On Linux, Sync 1.0.1 prints "Fired, ok", but Sync 1.1.0 prints "Not fired?". ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74120&edit=1