[MDEV-26104] PHP PDO with bind variables crashing 10.2.39 Created: 2021-07-07  Updated: 2021-10-25  Resolved: 2021-10-25

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 10.2.39
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Kevin Andrews Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: need_feedback


 Description   

Might be related to MDEV-16148

Looks like a regression as 10.2.38 runs our query through PHP PDO without crashing the mariadb server.

Switching our container up to either 10.2 or 10.2.39 crashes the entire mariadb instance when running our query through PHP PDO, however MySQL command line and through DBeaver work fine.

I can try to replicate with a simpler query if needed, however this query it is crashing on is a complex one.

Logs:

[ERROR] mysqld got signal 11 ;
 
edkrc  This could be because you hit a bug. It is also possible that this binary
 
edkrc  or one of the libraries it was linked against is corrupt, improperly built,
 
edkrc  or misconfigured. This error can also be caused by malfunctioning hardware.
 
edkrc  
edkrc  To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
edkrc  
edkrc  We will try our best to scrape up some info that will hopefully help
 
edkrc  diagnose the problem, but since we have already crashed,
 
edkrc  something is definitely wrong and this may fail.
 
edkrc  
edkrc  Server version: 10.2.39-MariaDB-1:10.2.39+maria~bionic
 
edkrc  key_buffer_size=134217728
 
edkrc  read_buffer_size=67108864
 
edkrc  max_used_connections=32
 
edkrc  max_threads=102
 
edkrc  thread_count=37
 
edkrc  It is possible that mysqld could use up to
 
edkrc  key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 20187244 K  bytes of memory
 
edkrc  Hope that's ok; if not, decrease some variables in the equation.
 
edkrc  
edkrc  Thread pointer: 0x7f2458000c08
 
edkrc  Attempting backtrace. You can use the following information to find out
 
edkrc  where mysqld died. If you see no messages after this, something went
 
edkrc  terribly wrong...
 
edkrc  stack_bottom = 0x7f25544fbdd8 thread_stack 0x49000
 
edkrc  mysqld(my_print_stacktrace+0x2e)[0x560eebf77b2e]
 
edkrc  mysqld(handle_fatal_signal+0x513)[0x560eeba15983]
 
edkrc  /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f274ab3b980]
 
edkrc  [0x7f245800f820]
 
edkrc  
edkrc  Trying to get some variables.
 
edkrc  Some pointers may be invalid and cause the dump to abort.



 Comments   
Comment by Sergei Golubchik [ 2021-07-17 ]

Yes, please, try. It'd help a lot if we'd be able to repeat the crash.

Comment by Elena Stepanova [ 2021-08-18 ]

caffe1neadd1ct, have you had any luck with this?

Comment by Kevin Andrews [ 2021-08-18 ]

Query ran fine on 10.2.39 through dbeaver and mysql client, only caused crashes through the PHP application, had to roll back to 10.2.38 to resolved the mysql server crashing as it's an operational application.

I've fired up a local docker instance of 10.2.39-bionic and no error running the same query on empty tables of the same structure through a local copy of the PHP application.

Importing a sample dataset now, however i'm leaning toward an issue with our specific setup/environment which should be interesting to track down.

Comment by Kevin Andrews [ 2021-08-18 ]

Sample dataset loaded, still no error through the local PHP application and a fresh docker 10.2.39

I'll put more time in to test with a copy of the application's docker php setup with the fresh 10.2.39 docker instance and see if it's something to do with our PHP docker version and bound vars / PDO.

Comment by Sergei Golubchik [ 2021-10-25 ]

For now I'll close the issue as "Incomplete" as there was no feedback for a month. But don't worry we'll reopen it if you reply with something to us to work on

Generated at Thu Feb 08 09:42:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.