8000 Fatal error: Unsupported operand types in ResourceCaster::castStream · Issue #23151 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Fatal error: Unsupported operand types in ResourceCaster::castStream #23151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
VadimKulagin opened this issue Jun 12, 2017 · 4 comments
Closed

Fatal error: Unsupported operand types in ResourceCaster::castStream #23151

VadimKulagin opened this issue Jun 12, 2017 · 4 comments
Labels
Bug Status: Needs Review VarDumper

Comments

@VadimKulagin
Copy link
VadimKulagin commented Jun 12, 2017 •
edited
Loading
Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Symfony version 3.3.2

I have the following standard logging configuration for dev environment:

monolog:
    handlers:
        main:
            type: stream
            path: '%kernel.logs_dir%/%kernel.environment%.log'
            level: debug
            channels: ['!event']
        console:
            type:   console
            process_psr_3_messages: false
            channels: ['!event', '!doctrine', '!console']
        server_log:
            type:   server_log
            process_psr_3_messages: false
            host: 127.0.0.1:9911

I found the problem that when a 500th error occurs (because of the PHP Fatal error – Call to a member function getCategory() on null), the web debug toolbar is not loaded, and then pop-up appears with the text: "An error occurred while loading the web debug toolbar (404: Not Found)".

In the error log, I found that another fatal error occurs in the ResourceCaster::castStream method:

Unsupported operand types in .../vendor/symfony/symfony/src/Symfony/Component/VarDumper/Caster/ResourceCaster.php on line 44

Here's the code snippet that leads to the error:

$a = stream_get_meta_data($stream) + static::castStreamContext($stream, $a, $stub, $isNested);

I think that it is worth doing the validation of the value of $a and the result of castStreamContext before adding them to solve this problem. How do you think?

My logs here:
error.txt

And, by the way, if you pay attention to the logs, you can find another problem:

Warning:  call_user_func() expects parameter 1 to be a valid callback, cannot access private method Symfony\Bridge\Monolog\Handler\ServerLogHandler::nullErrorHandler() in .../vendor/symfony/symfony/src/Symfony/Component/VarDumper/Cloner/AbstractCloner.php on line 205

I think the nullErrorHandler method should be public.
@nicolas-grekas nicolas-grekas self-assigned this Jun 13, 2017
@nicolas-grekas
Copy link
Member

The nullErrorHandler-related issue is fixed by #23082
About the issue in castStream, I really don't know how that can happen.
Do you still experience any issue after #23082?

@nicolas-grekas nicolas-grekas removed their assignment Jun 13, 2017
@VadimKulagin
Copy link
Author
VadimKulagin commented Jun 13, 2017 •
edited
Loading

After #23082 I do not observe the problem with nullErrorHandler, thanks.

And about the "Fatal error: Unsupported operand types" - I myself can not say exactly why this happens, but say that this happens only when using server_log. I tested this with the "bin/console server:log" on and off.

I added a value check to the array to castStream and, in case of an error, added var_dump. That's what happened, maybe this will somehow help:

  'stream' => resource(202, persistent stream)
  'a' => 
    array (size=7)
      'timed_out' => boolean false
      'blocked' => boolean false
      'eof' => boolean false
      'stream_type' => string 'tcp_socket/ssl' (length=14)
      'mode' => string 'r+' (length=2)
      'unread_bytes' => int 0
      'seekable' => boolean false
  'context' => boolean false
  'stub' => 
    object(Symfony\Component\VarDumper\Cloner\Stub)[925]
      public 'type' => string 'resource' (length=8)
      public 'class' => string 'persistent stream' (length=17)
      public 'value' => resource(202, persistent stream)
      public 'cut' => int 0
      public 'handle' => int 202
      public 'refCount' => int 0
      public 'position' => int 0
      public 'attr' => 
        array (size=0)
          empty
  'isNested' => boolean true

My configuration is:

PHP 5.6.30 (cli) (built: Feb  7 2017 16:18:37) 
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

On macOS Sierra 10.12.5 (16F73)

@nicolas-grekas
Copy link
Member

where is this "context" entry coming from?

@nicolas-grekas
Copy link
Member

cal you please try this patch?

--- a/src/Symfony/Component/VarDumper/Caster/ResourceCaster.php
+++ b/src/Symfony/Component/VarDumper/Caster/ResourceCaster.php
@@ -50,7 +50,7 @@ class ResourceCaster
 
     public static function castStreamContext($stream, array $a, Stub $stub, $isNested)
     {
-        return stream_context_get_params($stream);
+        return stream_context_get_params($stream) ?: array();
     }

@nicolas-grekas nicolas-grekas mentioned this issue Jun 14, 2017
Merged
fabpot added a commit that referenced this issue Jun 14, 2017
@fabpot
bug #23176 [VarDumper] fixes (nicolas-grekas)
d1104da 
This PR was merged into the 2.7 branch.

Discussion
----------

[VarDumper] fixes

| Q             | A
| ------------- | ---
| Branch?       | 2.7
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #23115 and #23151 (hopefully)
| License       | MIT
| Doc PR        | -

it looks like stream_context_get_params can return false (looking at php-src and #23151)
and doing a foreach on SplObjectStorage changes its internal iterator state.

Commits
-------

d7238c9 [VarDumper] fixes
@fabpot fabpot closed this as completed Jun 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Status: Needs Review VarDumper
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fabpot @nicolas-grekas @xabbuh @VadimKulagin @carsonbot
0