Why does yield result in error with doctrine collection?

[NotionCommotion]

Anyone know why the following results in an error?  Not a big deal as memory is not an issue and I can (and have) just changed it to create a new array instead of using a generator, but still curious.  Thanks

<?php
foreach($doctrineCollection as $doctrineEntity){
    yield new MyWrapper($doctrineEntity);
    /*
    After around 4 iterations, results in the following error:
    
    syslog
    Apr 06 15:25:25 myserver.net kernel: php-fpm[42889]: segfault at 7f8156a14100 ip 000055bb1d79acfd sp 00007ffd0b50a968 error 4 in php-fpm[55bb1d47c000+46e000]

    /var/log/php-fpm/error.log
    [Mon Apr 06 20:06:38.781360 2020] [proxy_fcgi:error] [pid 1501:tid 140210423629568] (104)Connection reset by peer: [client 12.345.67.890:45574] AH01075: Error dispatching request to :

    /var/log/httpd/error_log
    [06-Apr-2020 20:04:52] WARNING: [pool michael] child 5524 exited on signal 11 (SIGSEGV) after 0.138268 seconds from start
    [06-Apr-2020 20:04:52] NOTICE: [pool michael] child 5526 started
    */
}

class MyWrapper
{
    private $doctrineEntity;

    public function __construct($doctrineEntity)
    {
        $this->doctrineEntity=$doctrineEntity;
    }
}

 

[requinix]

PHP should almost never segfault. Can you get a backtrace?

[NotionCommotion]

On 4/7/2020 at 1:03 PM, requinix said:

PHP should almost never segfault. Can you get a backtrace?

Trying but haven't yet been successful.  Looking at https://ma.ttias.be/generate-php-core-dumps-segfaults-php-fpm/, however, echo '/tmp/coredump-%e.%p' > /proc/sys/kernel/core_pattern returns permission denied.  I know it is possible to do using tee, but instead just tried to edit /proc/sys/kernel/core_pattern using vi (was previously "core" so I figured I can just set it back).  Wasn''t as easy as i though, and couldn't get my non-default pools running until rebooting the machine..

Any recommend approach to get a bactrace using php-fpm?

[requinix]

You probably need root to change core_pattern, so

echo '/tmp/coredump-%e.%p' | sudo tee /proc/sys/kernel/core_pattern

You need root at the moment you try to open core_pattern for writing. echo> only works if you're running as root in the shell (since the shell is what tries to open the file), and sudo echo> will only run the echo as root (which won't do anything).

If you can reproduce the crash with a CLI command then that's easier. If not, get the core dump and give it to gdb.

[NotionCommotion]

I updated the core_pattern, added rlimit_core = unlimited to the pool, and restarted php-fpm.  I no longer get the error.

Still would like to know what is causing it as setting limits to unlimited doesn't sound like a good idea.  Added the following to index.php, executed sudo -upool1user dump.php (pool1user is needed for postgres)

$server_json=json_encode($_SERVER);
$script=<<<EOL
<?php
\$_SERVER=json_decode('$server_json',true);
include 'index.php';
EOL;
file_put_contents('dump.php', $script);

I then still get the segfault error, however, don't seem to generate a dump.  Not sure whether related to the segfault or the inability to create a dump, I do view a couple PAM issues (don't know what PAM is).

Apr 09 20:39:08 devserver sudo[4385]: PAM unable to dlopen(/usr/lib64/security/pam_fprintd.so): /usr/lib64/security/pam_fprintd.so: cannot open shared object file: No such file or directory
Apr 09 20:39:08 devserver sudo[4385]: PAM adding faulty module: /usr/lib64/security/pam_fprintd.so
Apr 09 20:39:08 devserver sudo[4385]:  michael : TTY=pts/1 ; PWD=/var/www/dataapp/public ; USER=pool1user ; COMMAND=/bin/php dump.php
Apr 09 20:39:08 devserver sudo[4385]: pam_unix(sudo:session): session opened for user pool1user by michael(uid=0)
Apr 09 20:39:09 devserver kernel: php[4386]: segfault at 7f961124c100 ip 000055f84d42e0cd sp 00007ffd7ca1c608 error 4 in php[55f84d0ff000+472000]

Also, https://bugs.php.net/bugs-generating-backtrace.php states the following.  Looking at phpinfo, I don't think it is enabled.  Currently using remi's repo for my php installations, an maybe need to compile?

Quote

To get a backtrace with correct information you must have PHP configured with --enable-debug!

Any thoughts?  Thanks

[requinix]

48 minutes ago, NotionCommotion said:

I then still get the segfault error, however, don't seem to generate a dump.

To test whether you can get a dump, try crashing PHP:

$ php -r 'posix_kill(posix_getpid(), SIGSEGV);'

48 minutes ago, NotionCommotion said:

  Not sure whether related to the segfault or the inability to create a dump, I do view a couple PAM issues (don't know what PAM is).

Authentication system. That error is something you should look into.

48 minutes ago, NotionCommotion said:

Also, https://bugs.php.net/bugs-generating-backtrace.php states the following.

--enable-debug keeps more information in the PHP binary that makes backtraces more useful than without. You don't need it to generate a coredump or get a backtrace.

What the backtrace can hopefully tell us is a general indication of where the problem happened - maybe it was within PHP, maybe it was within php-fpm, maybe it was from an extension, that sort of thing. That's at least a first step. Hopefully don't need the extra information in a debug build.

[kicken]

What platform and PHP version are you using?   Can you create some minimal example code that can recreate the crash?

I tried setting up some code in a way similar to what you suggest (though I'm not sure what exactly you might be doing and may have got it wrong) and had no issues on windows 10/php 7.3.16

 

[NotionCommotion]

9 hours ago, requinix said:

To test whether you can get a dump, try crashing PHP:

Displays "Segmentation fault" but no dump.  PS, segfault came back when using with php-fpm even after setting rlimit_core = unlimited.

9 hours ago, requinix said:

Authentication system. That error is something you should look into.

Happens whenever I execute "sudo -uOtherUser php bla.php" and "sudo php bla.php", but not when I switch users and then execute "php bla.php".  Do you mind trying to execute a php file as sudo and check journalctl for all units?  Don't know where to start looking into this one. 

9 hours ago, requinix said:

--enable-debug keeps more information in the PHP binary that makes backtraces more useful than without. You don't need it to generate a coredump or get a backtrace.

Where would I be able to view this backtrace?  In /tmp or somewhere else?

[michael@devserver public]$ cat /proc/sys/kernel/core_pattern
/tmp/coredump-%e.%p
[michael@devserver  public]$ ls -l /tmp
total 0
drwx------ 3 root root 16 Apr  9 18:29 systemd-private-809bd1f0c8db495c945df5ac824728c0-httpd.service-dJTl21
drwx------ 3 root root 16 Apr  9 18:29 systemd-private-809bd1f0c8db495c945df5ac824728c0-ntpd.service-iTmi5U
drwx------ 3 root root 16 Apr  9 20:30 systemd-private-809bd1f0c8db495c945df5ac824728c0-php72-php-fpm.service-M1mHap
drwx------ 3 root root 16 Apr  9 20:30 systemd-private-809bd1f0c8db495c945df5ac824728c0-php-fpm.service-2mtExV
drwx------ 2 root root  6 Apr  9 18:29 vmware-root_826-2990547547
drwx------ 2 root root  6 Apr  6 15:49 vmware-root_843-4021784525
[michael@devserver  public]$

 

Edited April 10, 2020 by NotionCommotion

[NotionCommotion]

7 hours ago, kicken said:

What platform and PHP version are you using?   Can you create some minimal example code that can recreate the crash?

I tried setting up some code in a way similar to what you suggest (though I'm not sure what exactly you might be doing and may have got it wrong) and had no issues on windows 10/php 7.3.16

 

CentOS Linux 7 (Core) Linux 3.10.0-1062.18.1.el7.x86_64 and PHP Version 7.4.3 on vmware.

Sorry, meant to include the following in my initial post.

function test(\Doctrine\ORM\PersistentCollection $collection) {
    foreach($collection as $entity){
        yield new MyWrapper($serie);
        //$items[]=new MyWrapper($entity);  //Doesn't not result in error which solves my problem and am only investigating for curiosity's sake
    }
    //return $items;
}

 

[requinix]

3 hours ago, NotionCommotion said:

Sorry, meant to include the following in my initial post.

That code doesn't look quite right. Try again?

[requinix]

4 hours ago, NotionCommotion said:

Displays "Segmentation fault" but no dump.

Then core dumps aren't working yet.

4 hours ago, NotionCommotion said:

Where would I be able to view this backtrace?  In /tmp or somewhere else?

A backtrace is what you get from gdb when it looks at a core dump, or sees the crash as it happens.

Okay, try this: stop php-fpm, set it up to spawn only one child, then use gdb like

$ gdb `where php-fpm`
(gdb) set follow-form-mode child
(gdb) run

Then crash PHP and see if gdb can catch the segfault. If so, post the output to

(gdb) bt

 

[NotionCommotion]

8 hours ago, requinix said:

That code doesn't look quite right. Try again?

Partially replaced "$serie" with "$entity" to indicate it was a doctrine entity, but didn't do my part.

 

8 hours ago, requinix said:

Then core dumps aren't working yet.

A backtrace is what you get from gdb when it looks at a core dump, or sees the crash as it happens.

Okay, try this: stop php-fpm, set it up to spawn only one child, then use gdb like

$ gdb `where php-fpm`
(gdb) set follow-form-mode child
(gdb) run

Then crash PHP and see if gdb can catch the segfault. If so, post the output to

(gdb) bt

 

Maybe the issue.  While I know gdb is relevant and even recently made sure it was installed, I know nothing about it and didn't know it was even required to be used or that I needed to execute it.  Will investigate.  Thanks