Jump to content

Recommended Posts

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;
    }
}

 

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?

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.

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

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:

--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.

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

 

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 by 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;
}

 

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

 

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

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.