shared mem & struct.
in [Unix Programming]
|
Prev: gdb question
Next: And, following a series of proxy sites blocked open any page or download from RapidShare download sites have all accelerated the internet da free
From: David Given on 22 Mar 2010 19:22 On 22/03/10 17:53, Vandana wrote: [...] > shm = (struct shared_mem*) shmat (shmid, NULL, 0); [...] > shm->emp = (struct emp*) shmat (shmid, NULL, 0); [...] > By doing the above, am I allocating memory for pointer to emp & > pointer to dob within the shared memory? As far as I can tell (and it's late and so I could very well be wrong), this still won't work. You have no control over where your two blocks will be mapped, therefore your pointers won't be valid in a different process where they're mapped somewhere else. I think you're not going to have any luck with this approach. Your best bet is probably to use indices into an array of objects stored in the shared memory segment. By avoiding pointers completely, the problem goes away. As the shared memory segment is of fixed size, a heap isn't that useful anyway, so it's not much more inconvenient (although I appreciate that it is still a little inconvenient). -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL
From: Vladimir Jovic on 23 Mar 2010 04:50 David Given wrote: > On 22/03/10 17:53, Vandana wrote: > [...] >> shm = (struct shared_mem*) shmat (shmid, NULL, 0); > [...] >> shm->emp = (struct emp*) shmat (shmid, NULL, 0); > [...] >> By doing the above, am I allocating memory for pointer to emp & >> pointer to dob within the shared memory? > > As far as I can tell (and it's late and so I could very well be wrong), > this still won't work. You have no control over where your two blocks > will be mapped, therefore your pointers won't be valid in a different > process where they're mapped somewhere else. > > I think you're not going to have any luck with this approach. Your best > bet is probably to use indices into an array of objects stored in the > shared memory segment. By avoiding pointers completely, the problem goes > away. As the shared memory segment is of fixed size, a heap isn't that > useful anyway, so it's not much more inconvenient (although I appreciate > that it is still a little inconvenient). > Vandana can use mmap to get a pointer to the specific memory address.
From: Rainer Weikusat on 23 Mar 2010 08:44 Vladimir Jovic <vladaspams(a)gmail.com> writes: > David Given wrote: >> On 22/03/10 17:53, Vandana wrote: >> [...] >>> shm = (struct shared_mem*) shmat (shmid, NULL, 0); >> [...] >>> shm->emp = (struct emp*) shmat (shmid, NULL, 0); >> [...] >>> By doing the above, am I allocating memory for pointer to emp & >>> pointer to dob within the shared memory? >> >> As far as I can tell (and it's late and so I could very well be wrong), >> this still won't work. You have no control over where your two blocks >> will be mapped, therefore your pointers won't be valid in a different >> process where they're mapped somewhere else. >> >> I think you're not going to have any luck with this approach. Your best >> bet is probably to use indices into an array of objects stored in the >> shared memory segment. By avoiding pointers completely, the problem goes >> away. As the shared memory segment is of fixed size, a heap isn't that >> useful anyway, so it's not much more inconvenient (although I appreciate >> that it is still a little inconvenient). >> > > Vandana can use mmap to get a pointer to the specific memory address. In theory, yes. In practice, programs are not supposed to be aware of their own address space layout since this collides with the political necessity to provide OpenBSD invented "they will never figure out how to exploit THAT!" pseudo security hacks[*] (like 'address space randomization'). [*] The problem is the buggy code, not that someone may be capable to exploit those bugs.
From: Tim Bowler on 23 Mar 2010 08:47 On 03/22/2010 07:22 PM, David Given wrote: > On 22/03/10 17:53, Vandana wrote: > [...] >> shm = (struct shared_mem*) shmat (shmid, NULL, 0); > [...] >> shm->emp = (struct emp*) shmat (shmid, NULL, 0); > [...] >> By doing the above, am I allocating memory for pointer to emp& >> pointer to dob within the shared memory? > > As far as I can tell (and it's late and so I could very well be wrong), > this still won't work. You have no control over where your two blocks > will be mapped, therefore your pointers won't be valid in a different > process where they're mapped somewhere else. > > I think you're not going to have any luck with this approach. Your best > bet is probably to use indices into an array of objects stored in the > shared memory segment. By avoiding pointers completely, the problem goes > away. As the shared memory segment is of fixed size, a heap isn't that > useful anyway, so it's not much more inconvenient (although I appreciate > that it is still a little inconvenient). > To save addresses in shared memory, we always subtracted off the base address of the shared memory and stored the offsets. Whenever they're to be used as addresses, each process would have to add their base address of the shared memory to the offset.
From: Vladimir Jovic on 23 Mar 2010 09:35
Rainer Weikusat wrote: > Vladimir Jovic <vladaspams(a)gmail.com> writes: >> David Given wrote: >>> On 22/03/10 17:53, Vandana wrote: >>> [...] >>>> shm = (struct shared_mem*) shmat (shmid, NULL, 0); >>> [...] >>>> shm->emp = (struct emp*) shmat (shmid, NULL, 0); >>> [...] >>>> By doing the above, am I allocating memory for pointer to emp & >>>> pointer to dob within the shared memory? >>> As far as I can tell (and it's late and so I could very well be wrong), >>> this still won't work. You have no control over where your two blocks >>> will be mapped, therefore your pointers won't be valid in a different >>> process where they're mapped somewhere else. >>> >>> I think you're not going to have any luck with this approach. Your best >>> bet is probably to use indices into an array of objects stored in the >>> shared memory segment. By avoiding pointers completely, the problem goes >>> away. As the shared memory segment is of fixed size, a heap isn't that >>> useful anyway, so it's not much more inconvenient (although I appreciate >>> that it is still a little inconvenient). >>> >> Vandana can use mmap to get a pointer to the specific memory address. > > In theory, yes. In practice, programs are not supposed to be aware of > their own address space layout since this collides with the political > necessity to provide OpenBSD invented "they will never figure out how > to exploit THAT!" pseudo security hacks[*] (like 'address space > randomization'). > > [*] The problem is the buggy code, not that someone may be > capable to exploit those bugs. I agree. She should use the array stored in the shared memory, and just pass the index of the element from one process to another. |