Re: shm and MacOs

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 - 19:22:55 MDT