db_strerror is thread safe?

I intend to use db_strerror with posix threads.

How thread safe it is?

This is not actually documented in available docs.

Thanks in advance.

Regards
ramana

The db_strerror routine is thread-safe as long as the error return is a
standard error, that is, as long as the application does not give
random numbers to the function. Regardless, the worst thing that can
happen is that an error string might be overwritten, there are no worse
consequences.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (Yahoo IM)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com

bostic (AT) sleepycat (DOT) com writes:

Regardless, the worst thing that can
happen is that an error string might be overwritten, there are no worse
consequences.

Really? Those are \0 terminated strings. Consider the case where a
smaller error string is overwritten with a longer one, presumably
from front to rear: there will be a moment where the old \0 has already
been overwritten, but the new, later \0 has not been written. Use of
the string, by another thread, at that moment, would lead to arbitrarily
unbounded memory reads.

best regards
Patrick

Fair enough -- of course, you'd have to have different numbers of
digits in the error value, and you'd have to be de-scheduled between
over-writing the nul and before writing your own nul into the next byte
or so. :-)

I'm open to ideas, what solution would you suggest?

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (Yahoo IM)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com

Fair enough -- of course, you'd have to have different numbers of
digits in the error value, and you'd have to be de-scheduled between
over-writing the nul and before writing your own nul into the next byte
or so. :-)

I'm open to ideas, what solution would you suggest?

Use strerror_r where available. Some systems which lack it (Solaris,
IIRC) have a thread-safe strerror, using thread-local storage.

Thanks, Florian -- that's a good suggestion, I hadn't thought of that.

That approach requires a change in the Berkeley DB db_strerror API (or
a new API, db_strerror_r, I suppose). Is there enough risk here to
make an API change necessary?

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com

bostic (AT) sleepycat (DOT) com writes:

That approach requires a change in the Berkeley DB db_strerror API (or
a new API, db_strerror_r, I suppose). Is there enough risk here to
make an API change necessary?

I think that the possibility of inadvertant unbounded memory reads
would be something that needs fixing even if it is rather unlikely.

But, looking at the code (unknown_err: in common/db_err.c), I find
that there really isn't such a problem. There will always be some
\0 before the end of ebuf[], unless int becomes larger than 64 bit,
and snprintf is broken.

So this leaves a problem of error message accuracy, and only for the
case where two threads output a different and unknown error code.
This is probably not a very urgent concern.

However, if in the real world use of strerror_r over strerror
is becoming the norm, adding db_strerror_r (while keeping
db_strerror) would be a good thing. People will be pleasantly
surprised to find what they expect.

best regards
Patrick

This is an quite interesting.

On Linux strerror_r is there, but man page documents the standard
version and non standard GNU version.

Both are quite different in usage and one has to figure out how
actually it works when it compiled!!!

Solution? I gave up on strerror_r and use plain strerror surrounded by
pthread_mutex_lock. These errors are very rare and few and are mostly
critical and exit(1).

Therefore almost no performance hit in my experience.

This is an quite interesting.

On Linux strerror_r is there, but man page documents the standard
version and non standard GNU version.

Both are quite different in usage and one has to figure out how
actually it works when it compiled!!!

Solution? I gave up on strerror_r and use plain strerror surrounded by
pthread_mutex_lock. These errors are very rare and few and are mostly
critical and exit(1).

Therefore almost no performance hit in my experience.

* Patrick Schaaf:

I think that the possibility of inadvertant unbounded memory reads
would be something that needs fixing even if it is rather unlikely.

But, looking at the code (unknown_err: in common/db_err.c), I find
that there really isn't such a problem. There will always be some
\0 before the end of ebuf[], unless int becomes larger than 64 bit,
and snprintf is broken.

strerror itself needs to access the system message catalogs (at least
unless the process runs in the C locale). All kinds of bad things can
happen if that is not serialized properly.