You can write a small C program that takes the id and log file as arguments. The utilities I'm aware that let you view shared memory segments are specific to the application using the shared memory.<div><br></div><div>
<a href="http://www.cs.cf.ac.uk/Dave/C/node27.html#SECTION002761000000000000000">http://www.cs.cf.ac.uk/Dave/C/node27.html#SECTION002761000000000000000</a><br><br><div class="gmail_quote">On Thu, May 12, 2011 at 12:10 PM, Jim Ockers <span dir="ltr"><<a href="mailto:ockers@ockers.net">ockers@ockers.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
<font size="+1"><tt>Hi CLUEbies,<br>
<br>
I have some processes that maintain a 340 byte data structure in memory
as a shared memory semaphore. I'd like to be able to grab the bytes
out of memory from time to time, without the cooperation or knowledge
of the processes that are reading & writing the data. We suspect
some sort of weird data corruption and I'd like to be able to produce
sort of a time-stamped "packet trace" of the semaphore data so we can
compare the values in memory with the expected values. Also what
happens is one of the processes crashes from time to time for no
apparent reason and we want to read the semaphore data out of memory at
the moment it crashes.<br>
<br>
This might be a n00b question but a google search wasn't helpful and so
I thought someone out there in CLUE-land might know.<br>
<br>
Here is ipcs output:<br>
<br>
[root /usr/sbin]# ipcs<br>
<br>
------ Shared Memory Segments --------<br>
key shmid owner perms bytes nattch status
<br>
0x00000000 0 root 600 1808 3
dest <br>
0x00000000 32769 root 600 340 3
dest <br>
0x00000000 65538 root 600 1728012 3
dest <br>
0x00000000 98307 root 600 1220 2
dest <br>
<br>
------ Semaphore Arrays --------<br>
key semid owner perms nsems status <br>
0x00000000 0 root 600 7 <br>
<br>
------ Message Queues --------<br>
key msqid owner perms used-bytes messages <br>
<br>
We want shmid 32769 with 340 bytes. How can I get it?<br>
<br>
[ userid ]$ cd /proc/sysvipc/<br>
[ userid /proc/sysvipc]$ ls -al<br>
total 0<br>
dr-xr-xr-x 2 root root 0 May 12 12:00 .<br>
dr-xr-xr-x 54 root root 0 May 11 09:35 ..<br>
-r--r--r-- 1 root root 0 May 12 12:00 msg<br>
-r--r--r-- 1 root root 0 May 12 12:00 sem<br>
-r--r--r-- 1 root root 0 May 12 12:00 shm<br>
[logger@mlogger /proc/sysvipc]$ cat sem<br>
key semid perms nsems uid gid cuid cgid
otime ctime<br>
0 0 600 7 0 0 0 0
1305223243 1305149770<br>
[logger@mlogger /proc/sysvipc]$ cat shm<br>
key shmid perms size cpid lpid nattch uid gid
cuid cgid atime dtime ctime<br>
0 0 1600 1808 580 670 3 0
0 0 0 1305150844 1305151313 1305149770<br>
0 32769 1600 340 580 670 3 0
0 0 0 1305150844 1305151313 1305149770<br>
0 65538 1600 1728012 580 670 3 0
0 0 0 1305150844 1305151313 1305149770<br>
0 98307 1600 1220 580 1104 2 0
0 0 0 1305150844 1305150844 1305149770<br>
[logger@mlogger /proc/sysvipc]$ cat msg<br>
key msqid perms cbytes qnum lspid lrpid uid
gid cuid cgid stime rtime ctime<br>
<br>
It seems I might just be able to dd the relevant bytes out of
/proc/kcore but I don't know where to find these bytes. Yes I suppose
I could do it the hard way and try to dump the whole 512MB kcore to a
file and then xxd and grep through it but that is inelegant. Is there
an elegant way to get NUMBEROFBYTESTOSKIP given what I know about the
semaphore from the SYSVIPC (system V inter-process communication)
information so I can do something like this:<br>
<br>
dd if=/proc/kcore skip=NUMBEROFBYTESTOSKIP bs=340 count=1 of=/tmp/dump<br>
<br>
Thanks,<br>
Jim<br>
</tt></font>
<pre cols="72">--
Jim Ockers, P.Eng. (<a href="mailto:ockers@ockers.net" target="_blank">ockers@ockers.net</a>)
Contact info: <a href="http://www.ockers.net/msi.html" target="_blank">http://www.ockers.net/msi.html</a>
</pre>
</div>
<br>_______________________________________________<br>
clue mailing list<br>
<a href="mailto:clue@cluedenver.org">clue@cluedenver.org</a><br>
<a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a><br></blockquote></div><br></div>