Re: shm and MacOs

On 04/14/2014 02:00 PM, Kinkie wrote:
> testRock does:
>
> shm_open(0x7FA3B9C06140, 0x202, 0x180) = 4 0
> ftruncate(0x4, 0x10418, 0x0) = -1 Err#22
>
>
> The test program:
> shm_open(0x10A183EC0, 0x202, 0x180) = 3 0
> ftruncate(0x3, 0x10418, 0x7FFF77B30638) = 0 0

> err 22 is EINVAL. I am quite curious about where the third argument to
> ftruncate comes from, and why it differs in the two runs.

Yes, the secret third argument appears to be the key here. It would be
nice to be able to see ftruncate's system call source code, but I am
guessing that is not possible with MacOS. Perhaps strace sources can
reveal the third argument's meaning?

Can you place your working code directly into testRock.cc? There may be
something in Squid itself (like a #define or build flag) that alters
ftruncate call environment...

> A possible alternative: since ftruncate is used to extend the shm
> area, what bout simply writing to it to extend it? Would it work in
> your opinion?

No idea about MacOs, but it worked on Linux -- the earlier code did
exactly that. The leftovers of that old code are still present in
fs/rock/RockSwapDir.cc. Look for SLOWLY_FILL_WITH_ZEROS.

Manual fill may slow down things a lot for large segments and slow disks
though. FWIW, a lot of documentation suggest ftruncate() as the right
solution here. We should resist manual fill if at all possible.

Cheers,

Alex.

> On Mon, Apr 14, 2014 at 9:22 PM, Alex Rousskov wrote:
>> On 04/14/2014 01:01 PM, Kinkie wrote:
>>
>>> The attached test program runs just fine on MacOS Mavericks; testRock
>>> fails, yet the code looks really the same as in src/ipc/mem/Segment.cc
>>> to me (after removing the O_TRUNC flag to shm_open).. can anyone spot
>>> a difference I can't see?
>>
>> Perhaps strace (or equivalent) would expose the critical difference?
>>
>> Also, this is a wild guess, but you may want to double check that old
>> shared memory segments are not interfering with one of your test cases.
>>
>> Alex.
>>
>>
>>> output:
>>> --------------
>>> mini:shm_test kinkie$ ./shm_test 66584
>>> start
>>> fd: 3
>>> sz: 66584
>>> mmap
>>> mem at 0x10dd9b000
>>> ok!
>>> --------------
>>> testRock:
>>> mini:squid kinkie$ gdb-apple ./src/tests/testRock
>>> [...]
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000068
>>> 0x00007fff92ff8eca in flockfile ()
>>>
>>> (gdb) bt
>>> #0 0x00007fff92ff8eca in flockfile ()
>>> #1 0x00007fff93001b10 in vfprintf_l ()
>>> #2 0x00007fff92ffa68e in fprintf ()
>>> #3 0x000000010000b4fb in fatal_common (message=0x1000fb8b0
>>> "Ipc::Mem::Segment::create failed to
>>> ftruncate(/squid-testRock_Store_i.shm, 66584): (22) Invalid
>>> argument\n") at fatal.cc:44
>>> #4 0x000000010000b4ab in fatal (message=0x1000fb8b0
>>> "Ipc::Mem::Segment::create failed to
>>> ftruncate(/squid-testRock_Store_i.shm, 66584): (22) Invalid
>>> argument\n") at fatal.cc:88
>>> #5 0x000000010000b600 in fatalf (fmt=<value temporarily unavailable,
>>> due to optimizations>) at fatal.cc:99
>>> #6 0x00000001000b257b in Ipc::Mem::Segment::create (this=0x100306810,
>>> aSize=66584) at mem/Segment.cc:78
>>> [...]
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
Received on Mon Apr 14 2014 - 21:07:25 MDT