mysql_store_result seems to say NULL is returned for errors (which is handled correctly, or 0 results like INSERT/ UPDATE). spider_db_mbase::exec_query where print_warnings seems to take an update, so looks valid.

I don't understand your mean.as you say,"mysql_store_result seems to say NULL is returned for errors".by looking at the source code of the mysql_store_result function, it can be seen that not all return null site will set errno to a non-zero value.So it is possible that the res ptr in the figure is null while errno is 0, so that the function print_warning does not return at line 2205,and dereference of null pointer res will occur at line 2209 in the graph.

ash1852 Thank you for the report.

According to the implementation, the above-mentioned null pointer dereference seems to be logically possible while it wouldn't be easy to find a test case that actually causes the null pointer dereference.

holyfoot Please review: https://github.com/MariaDB/server/commit/be0a46b3d52b58956fd0d47d040b9f4514406954

ok to push.

I've taken a look at nayuta's patch be0a46b3d52b58956fd0d47d040b9f4514406954 and would like to push it. holyfoot I assume you are still ok for it to be pushed?
hold on. I'm getting test failure for 10.4, patch applied to 603836e281a.

CURRENT_TEST: spider/bugfix.mdev_29644

mysqltest: At line 36: query 'INSERT INTO tbl_a VALUES ("this will be truncated")' failed: 1406: Data too long for column 'a' at row 1

I made some minor changes to the test case so that it passes 10.4. Can you take a look holyfoot? Thank you. https://github.com/MariaDB/server/commit/d346bd3ab03

see comment at the patch.
with that fixed ok to push.

Thanks for the comments and review, holyfoot. The comments were incorporated and patch pushed to 10.3.

Some merge conflicts needed to be handled, and below are patches for all versions:

• 10.3-4: 9b32e4b1923
• 10.5-8: b98375f9df0
• 10.9-11.0: 5075f4e0dae