Subject: lib/28986: realpath() is not thread safe
To: None <,,>
From: <>
List: netbsd-bugs
Date: 01/16/2005 19:09:00
>Number:         28986
>Category:       lib
>Synopsis:       realpath() is not thread safe, causes mysql bug on SMP
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 16 19:09:00 +0000 2005
>Originator:     "" <>
>Release:        NetBSD 2.0
System: NetBSD 2.0 NetBSD 2.0 (SUBTERRAIN) #1: Tue Dec 28 22:34:54 EST 2004 i386
Architecture: i386
Machine: i386
I uncovered some strange behavior on a NetBSD 2.0/i386 SMP machine and 
asked the guys on the mysql-general list to explain it. Here is what they 
said. To quote Dan Nelson:

"On FreeBSD, this was due to realpath not being thread-safe.  It called
chdir() internally and didn't prevent other threads from calling
chdir() or getcwd() at the same time.  NetBSD's realpath looks almost
identical to the old FreeBSD code, so it should be easy to fix by just
merging the fix from FreeBSD.

The FreeBSD fix is in rev 1.14."

The effect is that mysql's show databases command only shows "vi.recover"
as an available database. You are unable to select any of your existing
databases. A simple restart of mysql and the problem is gone, but it will
reoccur quickly on a loaded mysql server. The behavior reoccurs within a
few minutes on my machine handling 10 mysql connections/sec and 150 mysql 
queries/sec. I have not seen this behavior when I boot the machine with 
the non SMP kernel. Has anyone scoped out adapting FreeBSD's thread-safe 
realpath() into NetBSD or shall I take a stab at it?
Load an SMP kernel, ten or so mysql connections and do alot of realpath()
in your code. In this case the code was a search engine spider.

Adapt FreeBSD's thread-safe realpath() into NetBSD, because they already
identified and fixed this bug.