Okay, if anybody has the time to try them out: A patch for the original kfreebsd FTBFS: https://raw.githubusercontent.com/thomaslee/hiredis-debian/master/debian/patches/08_kfreebsd_ftbfs.patch
And a work-around for the race I observed in the "invalid timeout" tests: https://raw.githubusercontent.com/thomaslee/hiredis-debian/master/debian/patches/09_fix_test_race.patch Both have been forwarded upstream but have not yet been applied. If there are no pressing issues with these patches I'll request a new upload once upstream has had a chance to look things over. On Tue, Nov 17, 2015 at 3:40 AM, Tom Lee <deb...@tomlee.co> wrote: > 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> > > -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
