Possible data race in os.unix.c:5805:unixTempFileDir

(1) By 0xjnml on 2021-11-19 10:52:36 [link]

Hi.

A user of the Go transpiled SQLite library [is reporting a data race](https://gitlab.com/cznic/sqlite/-/issues/77).

It seems that at [L5819 and L5819](https://github.com/sqlite/sqlite/blob/4e86aa86ea0ab657423f1a715c620c188c6ba879/src/os_unix.c#L5818) the unixTempFileDir function is performing a lazy initialization of the first two items in the [azDirs array](https://github.com/sqlite/sqlite/blob/4e86aa86ea0ab657423f1a715c620c188c6ba879/src/os_unix.c#L5806).

This initialization is not protected by a mutex. Meaning unixTempFileDir is not thread safe per se. I was not able to quickly find if calls to unixTempFileDir are synchronized somewhere else, up the call stack.

I'll probably for now attempt a quick fix by a local patch adding a mutex around the lazy initialization, but I'd like to ask if someone more competent can verify if it is - or is not a bug in the SQLite3 code base. If that's the case it would save me from chasing a bug on my side.

Thanks in advance for anyone's kind help.

(2.1) By Larry Brasfield (larrybr) on 2021-11-19 16:33:12 edited from 2.0 in reply to 1

(Edited to correct hazard preconditions and reflect fix status.)

This is, technically, a race as claimed. The only potential harm would be when:<br>
Multiple threads initially request the temp directory name at (nearly) the same time in the same process;<br>
For different connections;<br>
On a build with 64-bit pointers;<br>
Running on a 32-bit machine.<br>

This is extremely unlikely to ever happen, of course. Nevertheless, a ["cure" has been checked into the source](https://sqlite.org/src/info/95806ac1dabe4598) (thanks to Dan.)

(3) By 0xjnml on 2021-11-19 15:52:35 in reply to 2.0 [link]

Thank you very much for taking care of this.