-
Notifications
You must be signed in to change notification settings - Fork 254
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.
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
mysqli_prepare can return false #7831
Comments
Also, note since #7815 has merged, I haven't tested to see how it affects the ease of reproducing it. |
in my eyes the fallback scenario is not a valid option, alternative fallback could be, |
The fallback was trying to do a standard query. But I realize the problem is that the database connection has failed. It wouldn't work either. I can't link the source as its a private discussion. What is happening is that the database connection is being blocked/rejected after the initial connection is made, SMF is trying to write to the error log and another error is occurring. The loop starts. Luckily we have some loop protection in the code and that is stopping things. I'm thinking the simple method for now would be to just bail out if we can't write to the error log. The bad here is that the error could be a non fatal error that would otherwise return silently and continue on. With such a change, the issue always becomes a fatal error. I like the idea of db_last_error but maybe a separate file. Then let a scheduled task check it and populate it into the error log. I think that is a 2.2 thing though. |
Any way, the loop detection came also from me i believe. |
I have also seen this error occur when trying to log an error that had a very large backtrace string. Specifically, the backtrace string was too large to fit in the backtrace field in the table, and so mysqli_prepare() returned false. I mention this because it means that connection problems are not the only way that this issue can be triggered. I don't know whether that information makes any difference regarding possible solutions, but it is worth knowing. |
Well in that case, truncating the backtrace would make sense. To do it safely, we would want to pop off the first 10 items of the backtrace. Everything after that is most likely a loop. |
Oh, shortening the backtrace in that case wasn't a problem and I easily solved it. (It was for custom code, and not relevant here.) The point of mentioning it was to say that there are multiple reasons why the prepare statement might return false. |
backtracer length is a mysql issue. |
here we go, here we go https://www.simplemachines.org/community/index.php?topic=586815.0 |
Description
Review the following code:
According to documentation on mysqli_prepare, it can return false on error. This will result in
mysqli_stmt_bind_param
returning a php error because $mysql_error_data_prep contains a bool, instead of the expected typemysqli_stmt
We need to address handling this case better. @albertlast as you wrote this code initially your inputs are useful.
I'm thinking we need to check if
$mysql_error_data_prep
returned boolean of false. If so, we fall back to using a standard insert. If that fails, we can't do anything. I'm thinking we should do a fatal error then since we don't have any database connection.The text was updated successfully, but these errors were encountered: