This was a much deeper rabbit hole than I expected, but I think I've worked it out. Most of the notes below are for my own benefit, but happy to elaborate if folks have any questions about the details. TL;DR is fmacros.h fails to detect kfreebsd as some sort of modern *nix & falls back to some old, weird implementation of strerror_r.
To confirm my initial suspicion that this was just a platform-specific issue wrt error messages, I passed EAGAIN to strerror_r in a trivial program on kfreebsd-amd64 and got the "Resource unavailable" message that the hiredis tests expected first try. Given this result, I couldn't understand why we were getting empty error strings in the hiredis tests but not in my little isolated test. Back to the drawing board. The failures have to do with the semantics of GNU vs. XSI-compatible implementations of strerror_r described here: http://man7.org/linux/man-pages/man3/strerror.3.html When running tests, hiredis behaves as though the implementation in use is the GNU version, sometimes not filling the buffer provided to strerror_r with the appropriate error message -- this explains why we get blank error messages, since hiredis believes us to be using the XSI-compatible version & the __redis_strerror_r macro doesn't do any of the requisite footwork to handle the odd behavior of GNU's strerror_r. If we modify __redisSetError to call strerror_r directly (instead of indirectly via __redis_strerror_r) then try to capture the output of strerror_r in a char *, we wind up with invalid pointers on amd64 since the XSI API returns a 32-bit int value. If we force -D_GNU_SOURCE, we get build errors due to some bad macros in hiredis' GNU implementation of __redis_strerror_r. These are easily fixed. Once fixed, everything works perfectly -- though the GNU semantics are kind of stupid. I modified the build to force -D_XOPEN_SOURCE=600 & removed -D_GNU_SOURCE. Suddenly everything was using XSI-compatible semantics. But why didn't I need to do this sort of thing in my trivial test of strerror_r to get the expected behavior? Believe the strange behavior is because hiredis fmacros.h #defines _XOPEN_SOURCE with no value/version since it can't detect kfreebsd as "some modern *nix". With this "versionless" define and nothing else, we get the weird GNU-impl-with-XSI-API behavior that causes our tests to fail. We can force the right behavior by avoiding the fall-through branch in fmacros.h on kfbsd ... just need to think a little on how best to do it: have the preprocessor detect kfreebsd, or remove the fall-through branch all together to fall back to system defaults. On top of all this, it also looks like the "Set error when an invalid timeout {,u}sec value is given to redisConnectWithTimeout" tests appear to be failing due to a race: the test seems to assume that the connect() call will fail, but it's succeeding immediately. As a result the code to do the validation of tv_usec/tv_sec never gets executed. I'll try to get a few patches together for all this later in the week. On Mon, Nov 16, 2015 at 11:27 PM, Tom Lee <deb...@tomlee.co> wrote: > Alrighty, despite my fdisk woes a bit of "printf debugging" has revealed > the test failure is simply that c->errstr doesn't contain the message the > test expects (instead errstr is an empty string). Easy enough to work > around: I'll put a patch together in a few minutes & drop it on here for > folks to verify. > > I'd still be interested to know how I can resize partitions on kfreebsd > for future reference :) > > On Mon, Nov 16, 2015 at 11:20 PM, Tom Lee <deb...@tomlee.co> wrote: > >> Thanks Steven, that was really helpful. Got Cristoph's image up & running >> in VirtualBox with a little playing around and I've been able to reproduce >> the issue. However, I've hit something of a newbie problem: there's >> insufficient space on the disk image to install gdb & actually take a >> closer look at what's going on. I've increased the size of the image itself >> but fdisk doesn't seem to play nice (I get "fdisk: cannot open /dev/ada0: >> Operation not permitted"). >> >> Is there some other tool I should be using to resize partitions under >> kfreebsd? >> >> On Sun, Nov 8, 2015 at 1:22 AM, Steven Chamberlain <ste...@pyro.eu.org> >> wrote: >> >>> Hello, >>> >>> Tom Lee wrote: >>> > I've had some trouble getting kfreebsd up and running in a VM >>> >>> Christoph has created a prebuilt VM image of jessie-kfreebsd, if that >>> helps you: >>> https://people.debian.org/~christoph/jessie-kfreebsd-vmimage.raw.xz >>> >>> Otherwise I will likely get around to looking at this bug myself. >>> >>> Regards, >>> -- >>> Steven Chamberlain >>> ste...@pyro.eu.org >>> >> >> >> >> -- >> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee> >> >> > > > -- > *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee> > > -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
