[MXS-27] bugzillaId-568: Code should use thread safe versions in C library Created: 2014-01-07  Updated: 2015-03-19

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 1.0.1
Fix Version/s: 1.0.6

Type: Bug Priority: Minor
Reporter: martin brampton (Inactive) Assignee: markus makela
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux


 Description   

This is imported from bugzilla item: http://bugs.mariadb.com/show_bug.cgi?id=568

Description martin.brampton@skysql.com 2014-10-07 08:50:50 UTC
Although some are currently safe, it is likely that some are not. It would be better, as a policy for present and future robustness to use thread safe versions of C library functions, or to explicitly protect them close to the point of use. For example crypt (crypt_r is available), getenv, getopt, localtime, rand (drand48_r may be an alternative), readdir (readdir_r is available), strtok (strtok_r is available). This is not necessarily an exhaustive list.

 Comments   
Comment by Dipti Joshi (Inactive) [ 2015-03-09 ]

This is history of comments from bugzilla:

Comment 1 Mark Riddoch 2014-12-03 09:07:39 UTC
config.c makes use of strtok, this should be changed to strtok_r.

adminusers.c calls crypt rather than crypt_r

getopt is not an issue since it is used before any threads are created.

readdir is only an issue in the binlog router

Time functions are used in diagnostics and should be moved to thread safe versions

Comment 2 Mark Riddoch 2014-12-03 09:56:51 UTC
Fixed strtok calls in core and plugins. Some calls remain in the test harnesses but these are single threaded and not an issue.

Fixed asctime and localtiem calls in diagnostics for server, service and session.

The calls to getenv an getopt occur before we create any threads are down before we create any threads so are not an issue.

Lowering the importance for the remainder of the issues

Comment 3 Markus Mäkelä 2015-02-16 07:38:36 UTC
Changed all calls to strtok to strtok_r where multiple threads are used.

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