Call to undefined method PDOStatement::setFetchMode() - php

I'm working with drupal 7, on PHP 7, on Xampp on Windows, and suddenly I start getting the following error:
Call to undefined method DatabaseStatementBase::setFetchMode()
Where DatabaseStatementBase extends PDOStatement directly. When reducing the code to the following minimum:
<?php
$dbh = new PDO('mysql:host=localhost;dbname=test', 'test', 'test');
$pdostatement = $dbh->prepare('SELECT * FROM items WHERE id=?');
$pdostatement->setFetchMode(PDO::FETCH_CLASS);
$success = $pdostatement->execute([1]);
// do stuff...
It still throws an error on the line regarding setFetchMode. When I comment that line out, no error is thrown, but I get an associative array instead of an object — not what drupal expects. Especially since setFetchMode should exist (see http://php.net/manual/en/pdostatement.setfetchmode.php)
Finally, when I then try to find the methods of the $pdostatement using reflection, I get garbage for some of the names — or, more accurately, the name seems about 1.5MB long and contains a lot of unreadable characters and some of the method names, as if an entire DLL was loaded in there or something. Here's an example of what var_dump (php7 & xdebug) make of it:
object(ReflectionMethod)[17]
public 'name' => string '����&������p�aZ������������ ���bindParam�������{�nZ���������������setAttribute����f�kZ����������j����FETCH_ORI_FIRST�a�pZ���������q��
���CURSOR_SCROLL���l�}Z���������������fetchColumn������zZ��������������wph�����&��������Z���������������debugDumpParams���Z��������.�����children����������Z������������wphX����&��������Z��������(��
���nextrowset��������Z������������
���__toString������ ��Z������������wph(����&������4��Z��������'... (length=1752201104)
public 'class' => string 'PDOStatement' (length=12)
How can I fix this?

The solution was: try turning it off and on again — in this case the Apache server. Apparently something got corrupted in memory, and restarting the server fixed it.
I assumed this was already done by me shutting down my computer yesterday, after the problem appeared, and booting it again this morning. Now I know: windows 8 and up use a hybrid shutdown/hibernate instead of a real shutdown, so your apache service doesn't really get restarted if you think you restarted your PC.
Somehow this makes me feel so dumb...

Related

phpstorm accept undefined variables

I'm trying to understand unexpected behavior by PHPstorm. I've two files without any include or required definitions.
// file1.php
<?php
$var = new class1();
// file2.php
<?php
class class1 { }
I would expect that class1 is undefined in file1, because file2 is not included. But phpstorm shows no warning. CTRL-B jumps to the declaration in file2. The option "Ignore include and require statements" is unchecked. Could someone explain this to me?
phpstorm doesn't know everything about your context. it is possible that the files are required by some other file one after another so everything will just work. Also there is a good chance, that you are using autoloader/composer (who doesn't?) which will take care of the issue.
So, I think they wouldn't consider this an error, as they wouldn't be able to properly filter false-positives if they enabled such warning
This is most likely a bug in PHPStorm itself, since PHP throws an exception.
Fatal error: Class 'class1' not found in /srv/www/htdocs/swaggityswoogityswoo/f1.php on line 5 Call Stack: 0.0003 629360 1. {main}() /srv/www/htdocs/swaggityswoogityswoo/f1.php:0
Since I upgraded to the latest versions, it seems to behave strange. For example, when i try to merge a file where the deployed adn the local file both contain contain 'text-align: left', he wants to merge it into 'text-align: center'.
Just wait until they release another version, maybe they'll be able to fix this bug.

Inexplicable type hinting in PHP code

I'm analyzing some PHP code which is running on a server I don't have full access to. I can read the phpinfo though. The code seems to run fine on the server. In my local environment I just can't get the code to run as I get a "Catchable Fatal Error" at some call of a method using type hinting.
someMethod(string $str) {
// Do something...
}
The error says the following: "Argument 1 passed to ... must be an instance of path\of\namespace\string, string given ...".
There is no use keyword with a string class nor can I find anything trough a grep command in the folders of the development environment.
Are there any PHP modules, extensions that can make such a type hinting work? The server and my development environment are using PHP 5.4.25.
What could the live system possibly provide to make such code run? Might it use some other programming language based on PHP like Hack? The rest of the code is pretty straight PHP!
You mention that there is no use statement or namespace declaration that alludes to a 'string' class in the code. Does the code use an Autoloader?
Two possible issues at hand here:
Paths - It is possible that the live environment has another path set up, and/or that a file/class is being loaded/searched for via this 'other path' (outside the code you may be looking at).
Error Handling - Another possible cause is if there is an error handler in the production environment that always returns true.
I had this exact issue where a type-hint wasn't resolving in development, but I didn't realize until we pushed it live and the error handler was no longer registered.
Obviously a fatal parse error can not be stopped, but it turns out a catch-able error can be ignored if the error handler returns true. And this is what I am putting my money on in your case.
Additionally, it is very important to note that there is no way to type-hint a scalar, as one user pointed out.
A simpler way to say it is "it is not possible to type-hint anything that can be represented by a string." This is due to the way in which PHP handles it's more primitive variables, they can all be type-cast to one another, and therefore (because 1, "1" and true can all be == 1, == '1' and == true) it is not actually possible for the interpreter as it is written to actually catch and enforce scalar type-hints.
Answer this question: Is that variable supposed to be $str = "something"; or $str = new string(); (ie, a string or an object)?
If it is supposed to be a string, remove the type-hint, as nothing in PHP allows this support (save for HHVM, but you would know this if you were using it).
Since you say you do not have access to the code, I suggest notifying someone who does.

Laravel 3 - PHP Warning: in_array() expects parameter 2 to be array

I am working with a code that was not written by me. It is a Laravel 3 application, it is giving me the following error:
PHP Warning: in_array() expects parameter 2 to be array, null given in /Users/use/Documents/project/laravel/error.php on line 87
Can you give me pointers on how to debug it? It is giving error in the file which was included in the framework. Also I using the php's inbuilt server to run the application. Does that cause problems? Any pointers are helpful.
PS: I am on a mac.
After looking at the source code it appears that you are getting the error from this file:
// laravel/error.php
// line 86
if (in_array($code, Config::get('error.ignore')))
{
return static::log($exception);
}
The method appears to be looking for the error.ignore config variable:
// application/config/error.php
// line 16
'ignore' => array(),
Check the application/config/error.php file, make sure that 'ignore' is set to an array. If it already is, then you likely have an error in one of the other config files which is corrupting the array.
Hopefully this helps and shows the steps you can take in tracking down the source of an error.
You can get this also if you're using composer and the required files have not been installed after a fresh checkout of the project. To resolve:
$ composer install
Or similar. To actually get a head on this information I had to throw $exception in the error.php file around line 87, then I saw the reason in the Apache error logs.
Most of this errors is about of parameters definition bug.
for example sometimes coder write
protected $guarded = 'title';
instead of
protected $guarded = ['title'];
That makes the paroblem

PHP 5.3.5 PDO FETCH_OBJ memory leak?

I'm currently developing an application in PHP which uses PDO. I'm writing an import which reads in a CSV file, checks the database for a record, and updates, deletes, etc....
Something which I've noticed is the memory being used by this script seems very high and it seems like it could be to do with the way I'm executing the query. see below for example query which is executed for each line in the CSV:
$qry = "SELECT * FROM company WHERE id = 1";
$sth = $this->prepare($qry);
$sth->execute();
$sth->setFetchMode(PDO::FETCH_INTO, new Company());
$sth->fetch();
for the above memory_get_peak_usage() = 6291456
When using the below:
$qry = "SELECT * FROM company WHERE id = 1";
$sth = $this->prepare($qry);
$sth->execute();
$sth->setFetchMode(PDO::FETCH_CLASS, "Company");
$sth->fetch();
for the above memory_get_peak_usage() = 524288
As you can see the difference is fairly big.
I guess I've 3 questions..
Is there a memory leak when using PDO::FETCH_OBJ in PHP 5.3.5?
Is there any difference between using FETCH_CLASS as opposed to FETCH_OBJ?
Has anyone else experienced the same issue?
Company Class is simple:
class Company {
function __construct(){}
/**classvars**/
public $_tablename = 'company';
public $transient;
public $id;
public $name;
/**endclassvars**/
}
Looking at the PHP changelog, there does appear to be a relevant fix in 5.3.4 where a memory leak was fixed in PDO FETCH_INTO.
From what you've said, I suspect that yes, this is the bug you're seeing. The solution, of course, is to upgrade -- there really is no point in sticking with an old patch release.
Even if this isn't the bug you're seeing, there have been a very large number of PDO fixes in the versions between 5.3.3 and now; I'm sure there's a good chance that at least some of them are relevant to you.
Note: the original answer was given before the OP changed PDO::FETCH_OBJ to PDO::FETCH_INTO
After that update I've tried to reproduce the behaviour using PHP 5.3.10-1ubuntu3.4. There where no significant difference in memory cosumption between both fetch modes. I've tested using a large MySQL table and a large SQLite database.
As #SDC mentioned the bug is known and was fixed after 5.3.5. (At least in 5.3.10 as I've seen).
Conclusion: You have to upgrade your PHP version.
Although the behaviour is interesting and should be investigated you are using PDO::setFetchMode() in a wrong way. When $mode - the first param - is PDO::FETCH_OBJ no second param is expected. If you use a second param the call to setFetchMode() will fail (returnin false) and the default fetch mode FETCH_BOTH will be used.
You can see this error when enabling PDO::ERRMODE_EXCEPTION :
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $db->query('....');
// the following line will trigger an exception
$stmt->setFetchMode(PDO::FETCH_OBJ, new Company());
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: fetch mode doesn't allow any extra arguments'
When you are expecting that result rows should objects of a specific class, then PDO::FETCH_CLASS is the working attempt. PDO::FETCH_OBJ will return objects from type StdClass
FETCH_INTO: Means fetching into an existing Object (that was created with new e.g.)
FETCH_CLASS: Means fetching into an new Object (the constructor is called every row)
Be careful, if the constructor in your Company class has dependencies, they are called for every row. Therefore the constructor should not contain functions or classes that do an DB connect e.g. only simple initializing...
How does your Company class look like?

Symfony2 PHPUnit, slightly long test, fatal error related to Monolog

I have narrowed my problem down to a single unit-test which involves a pretty clean dbal query. The query involves a nestedsets and the failure occurs when I go from 3 to 4 levels of hierarchical categories. Very little changes in terms of execution time.. And the functionality I'm work with has no problem at 10 level. However, in PhpUnit when I run the test with 4 or more levels -- I get a fatal error.
*To summarize, a query that may take a split second more than usual OR a tab bit more resources is getting me a php fatal error in PHPUnit *
And the Error Looks like this:
Fatal error: Call to undefined method Monolog\Formatter\LineFormatter::stopEvent() in /var/www/my-app/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Debug/Stopwatch.php on line 92
Someone here had a phpUnit fatal error problem on line 92 as well. Could it be related??
I've listed some quirky ways (below) to bypass my problem but I'd still like to know why such a basic test seems to be causing this problem.
Run PhpUnit with processIsolation set to "true".
Don't access the static::createClient(); in the setUpBeforeClass() method
I've had a respected member of #symfony (Stof) suggest that it looks like I'm improperly DI'ing #logger into a service.. but I've confirmed this doesn't seem to be the by taking the logger service out of any of my services.
Maybe this issue has something to do with a timeout? (The error mentions stopevent and stopwatch). Or maybe this error has something to do with accessing $client = static::createClient(); in setUpBeforeClass().. and then accessing is again in preceding tests.. Regardless.. it's confusing me and as far as I can tell, everything else in my Symfony2 (2.1.1) installation is working perfectly fine.
* LINE 92 of Stopwatch.php .. github source file here *
/**
* Stops an event.
* #param string $name The event name
* #return StopwatchEvent A StopwatchEvent instance
*/
public function stop($name)
{ return end($this->activeSections)->stopEvent($name);}
OK. So you grab the last item from the $this->activeSections array and they try to run the stopEvent() method on it. It would seem in this case that the LineFormatter class does not have that method available to it.
I am not familiar with Monolog, but in a brief glance at their latest GitHUb repo, I can see that neither the LineFormatter or NormalizerFormatter class which it inherits from have such a method.
It seems like Monolog is not playing nice with Symfony. And that without modifying Monolog and/or the Symfony Stopwatch class, you will not be able to use Stopwatch to profile your Monolog-related code.

Categories