[CONC-123] Non-block API and mysql_real_connect_start() issues Created: 2015-02-20  Updated: 2015-02-21

Status: Open
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: 0.9.1, 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sayed Assignee: Georg Richter
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux seiko 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) i686 GNU/Linux
gcc version 4.9.1 (Debian 4.9.1-19)
Server version: 10.1.0-MariaDB-1~wheezy-log mariadb.org binary distribution
-------------------------------------------------------------------------------------------
Linux iv-main 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux
gcc version 4.7.2 (Debian 4.7.2-5)
Server version: 10.1.2-MariaDB-1~wheezy-wsrep-log mariadb.org binary distribution, wsrep_25.10.r4123


 Description   

Hi guys,
I'm facing two issues with mysql_real_connect_start() in MariaDB connector c
mysql_real_connect_start() working almost fine in client version "100102"
except valgrind memcheck tool report switching stacks

so I decided to link against the last client version "50500" with the same code
but the issue still exist with extra problem that mysql_real_connect_start() ain't to connect and error is

" Lost connection to MySQL server at'handshake:
reading inital communication packet', system error: 11"
although the block function mysql_real_connect() is working fine.

Anyway thank you for reading my issue and I'm sorry for my poorly English skills



 Comments   
Comment by Kristian Nielsen [ 2015-02-20 ]

The valgrind message about switching stacks is expected. The non-blocking API is implemented using co-routines.

Comment by Sayed [ 2015-02-21 ]

First of all thank you for your attention,
Well I can deal with switching stacks .
the last client version "50500" I almost figure out the issues
Its because mysql_get_timeout_value_ms() always return 0 when I receive "MYSQL_WAIT_TIMEOUT"
then I changed timeout value to 1000ms for just a test and It works

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