On 25 February 2013 18:24, Alex Rousskov <[email protected]> wrote: > On 02/24/2013 10:02 PM, Amos Jeffries wrote: > >> I'm trying to get the MacOS builds of Squid going again but having some >> problems with shm_open() in the Rock storage unit-tests. >> >> 1) MacOS defines the max name length we can pass to shm_open() at 30 >> bytes. "/squid-testRock__testRockSearch" being 35 or so bytes. >> Cutting the definition in testRock.cc down so it becomes >> "/squid-testRock_Search" resolves that, but then we hit (2). > > That TESTDIR name is wrong because it is used for more than just > "search" testing. I bet the Rock name mimicked the UFS test name, but > the UFS name is wrong too, for the same reason. We should use > "cppUnitTestRock" and "cppUnitTestUfs" or something similarly unique and > short, I guess.
We should use a random name; squidtest-10-bytes-of-entropy should do it. Random because we don't want tests running in parallel to step on each other on jenkins slaves. > >> 2) With the short string above and the current settings sent to >> shm_open() in src/ipc/mem/Segment.cc line 73 MacOS shm_open() starts >> responding with EINVAL. > >> theFD = shm_open(theName.termedBuf(), O_CREAT | O_RDWR | O_TRUNC, >> S_IRUSR | S_IWUSR); > > > Sounds like some of the five shm_open() flags we are using successfully > elsewhere do not work on MacOS. I do not know which flag(s) do not work, > and we have no MacOS boxes in the lab, so we cannot experiment or read > documentation. > > I assume shared segment opening fails with similar symptoms when used > outside of unit tests (e.g., with a shared memory cache)? If so, please > feel free to disable shared memory support on MacOS (do not define > HAVE_SHM?) until somebody who needs it can find the right combination of > flags. +1 -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Cloud Services
