illumos gate

I experienced the following crash in an application that uses libuuid:

fffffc7fffdf4130 libc.so.1`mutex_lock_impl+0x33(0, 0)
fffffc7fffdf4150 libc.so.1`mutex_lock+0x10(0)
fffffc7fffdf41d0 libuuid.so.1`uuid_create+0x78(fffffc7fffdf41e0)
fffffc7fffdf4230 libuuid.so.1`uuid_generate_time+0x3c(fffffc7fffdf4248)

status: process terminated by SIGSEGV (Segmentation Fault), addr=4

This turned out to be a problem with permissions on /var/tmp, which is another story,
however I found a couple of things:

First is that, libuuid attempts to maintain a shared and persistent state file in
/var/sadm/system/uuid_state. It does not create this file if it does not exist
so presumably it is supposed to be delivered with some appropriate permissions.
If this file does not exist, the library falls back to a temporary state file via tmpfile().

When the fallback fails (as it did on my broken system), it doesn't fail in a particularly
friendly way, leaving the mutex uninitialised so that the crash occurs somewhere else.

It looks like this uuid_state file has never been delivered by packaging in the
illumos history, and that the parent directory (/var/sadm/system/) was removed
in

    commit 4d0eb50e691de4c20b1dd9976ad6839fede8a42d
    Author: Richard PALO <richard@netbsd.org>
    Date:   Wed Dec 17 14:22:16 2014 -0500

        4719 update gate build environment to [open]jdk7
        4742 update manifests for javadoc7
        4743 Fix deprecated /usr/j2se usage in slp and remove from filesystem(5) manpage
        4744 remove traces of /var/sadm/system/admin/default_java

We should work out if this shared state file should still be used, and whether by root or by
all users. If so, where should it be maintained (/var/sadm does not seem appropriate).

We should also make libuuid fail in a better way (earlier) when a state file cannot be created.