mysqli_prepare can return false about smf HOT 9 OPEN

Also, note since #7815 has merged, I haven't tested to see how it affects the ease of reproducing it.

from smf.

in my eyes the fallback scenario is not a valid option,
since the content could be dangerous.
So a bad guys could try to force here fallback scenario,
add dangerous stuff in the fallback scenario,
when our fallback scenario is normal insert.

alternative fallback could be,
that we write into db_last_error.php,
maybe wrap error stuff into a json string?

from smf.

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.

from smf.

Any way,
like you notice,
when this prepare approache failed,
than your smf is in very critical situation,
which means you ressources you can access is very limited,
so trying any thing fancy in this point of time would failed also.

the loop detection came also from me i believe.

from smf.

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.

from smf.

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.

from smf.

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.

from smf.

backtracer length is a mysql issue.

from smf.

here we go, here we go

https://www.simplemachines.org/community/index.php?topic=586815.0

from smf.