Reading/Writing to shared memory causes seg fault

[sean04]

Scenario:
One process (process A) creates a piece of shared memory and then execv's another process (process B) that reads/writes from this shared memory.

Problem:
Process A can read/write to memory ok but, Process B can read/write to this shared memory most of the time. Meaning that sometimes Process B is able to read/write to this memory while other times it just crashes and the Process dies during the memory access.

Can someone help?

Thanks.

[wje_lf]

Quoth sean04:

sometimes Process B is able to read/write to this memory while other times it just crashes and the Process dies during the memory access.

My first piece of advice is something you won't like: Question your assumptions. It's extreeeeeemely likely that the pointer does not point where you think it points (with apologies to Inigo Montoya in The Princess Bride).

Use gdb carefully. Alternatively, a rather unusual approach to the problem can be found here.

Hope this helps.

[sean04]

Thanks for the response.

My initial thought was the pointer as well but, I added debug to check the pointer and the pointer doesn't change from process A and to process B.

[wje_lf]

But usually the pointer in process B works anyway, so it does no good to ask simply, "Is the pointer the same in process A and process B?" Maybe what you need to ask is, "Under rare circumstances does something stomp on the pointer in process B so it's now bogus?"

[sean04]

When access to memory in process B fails, we do check that the pointer is not bogus prior to memory access.

Here's the scenario:

Program 1:
...
fork()
...
if(child)
{
pointer check
read/write shared memory
execv(program 2)
}

Program 2:
pointer check
read/write shared memory --> seg faults sometimes


In testing it, I stripped down program 2 to just do a pointer check and the read/write. Also, I added the read/write shared mem in program 1 right before the call to execv... and that call never fails, even when the program 2 one does.

[wje_lf]

I'm thinking several things here.

1. You can probably attach gdb to your running process B and see what things are like at the blowup.
2. If somehow process B losing access to the shared memory, does process A continue to have access to it? In either case, what if you had process A also fire up a process C whose only job was to check once a second whether the memory is accessible, and blow up with a SIGSEGV if not? If the process blows up about the same time process B does, that tells you something. If not, that tells you something also.
3. How is it exactly that you check that the pointer is still valid in process B?

[sean04]

I check the pointer by printing out the value to a file by using the %p formatting option.

[wje_lf]

I check the pointer by printing out the value to a file by using the %p formatting option.

That will work in all but the most devilish of circumstances, provided you do that printing before each and every use of the pointer.

Which leaves us with the other two points to ponder. :)

[wje_lf]

I just thought of something else.

Would this shared memory pointer be pointing to (perhaps among other things) an array?

And if so, do you check the index into that array? It should not exceed n-1, where n is the number of elements in the array, and it should not be negative, and you would do well to check the array index every time you use it.

[sean04]

No...there are no arrays or indices being used.

I printed out the /proc/<pid>/maps to a file and looked at the processes and the address spaces it occupies. I've noticed that under the pathname column I have a name "SYSV000007d4". Is this my shared memory?

If so, which it looks like, then I've noticed that when the pointer is within the address space of "SYSV000007d4" I have no problem writing/reading from shared memory, but when I seg fault, then the pointer is not within this address space. What's even more confusing is that program 1 (see previous postings) is able to access this shared memory but program 2 is not.

Any ideas what might be happening?