1

I am using shmat() by using a virtual address.

  • the first process calls a shmat with shmaddr as null and when it gets the virtual address of the data block it stores in another shared memeory place.

  • the second process calls the shmat() with the virtaul address that was stored in shared memeory by the first process.

  • The second process usually can attach to the same virtual address in most of the cases, but in one case I couldn't and shmat returned -1 and when I used gdb I saw that the address is a Bad address.

    (gdb) x 0x800852000
0x800852000:    Error accessing memory address 0x800852000: Bad address.

So my question is How do I guarantee that the first time I get virtual address that both processes can see?

pat_en
  • 63
  • 5

1 Answers1

1

In cases where you are setting the virtual address, its better if you force it to a value that is unlikely to be used normally. You most likely got the bad address because a library or something else took over before you had a chance to attach. We have a similar, situation and we force our address to 0x0000005000000000 (for 64bit systems):

void *stuff = shmat(shmid, 0x0000005000000000, SHM_RDONLY);
Missaka Wijekoon
  • 883
  • 7
  • 10
  • 3
    I have to say that if you can have the system choose the address for you it is better (and the preferred usage for shared memory) and makes your code more portable. – Missaka Wijekoon Mar 04 '11 at 01:11
  • 1
    I wanted to use fixed address to allow both process to read the contents at a specific address by storing the address. as in first process stores the address that the other process can read directly from...without having the offsets – pat_en Mar 04 '11 at 22:18
  • If you change your first process to take the shmaddr you set at an address range unlikely to be used (unless the process gets really big), then your problem should go away. But, when doing it this way there are no guarantees unless you are in complete control of what all code and libraries you use do. So, all you can do is pick an address range that is not likely to be used. In our case 0x0000005000000000 works every time. – Missaka Wijekoon Mar 05 '11 at 10:00
  • Misk can you give more insight why this particular address should work with almost all work load? Any link? – Huygens Oct 10 '11 at 14:24
  • Mostly trial/error and educated guesses. It probably depends on version of os, etc (hence why it is not portable.) Try doing a pmap on the process id of the process your are interested in to see how the os maps all the memory segments. Then you have to choose a segment that is valid and unlikely to be chosen automatically. – Missaka Wijekoon Nov 22 '11 at 18:02