[clue] [TECH] reading semaphore data using /proc/kcore?

[Will]

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.

http://www.cs.cf.ac.uk/Dave/C/node27.html#SECTION002761000000000000000

On Thu, May 12, 2011 at 12:10 PM, Jim Ockers <ockers at ockers.net> wrote:

>  Hi CLUEbies,
>
> 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.
>
> 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.
>
> Here is ipcs output:
>
> [root /usr/sbin]# ipcs
>
> ------ Shared Memory Segments --------
> key       shmid     owner     perms     bytes     nattch    status
> 0x00000000 0         root      600       1808      3         dest
> 0x00000000 32769     root      600       340       3         dest
> 0x00000000 65538     root      600       1728012   3         dest
> 0x00000000 98307     root      600       1220      2         dest
>
> ------ Semaphore Arrays --------
> key       semid     owner     perms     nsems     status
> 0x00000000 0         root      600       7
>
> ------ Message Queues --------
> key       msqid     owner     perms     used-bytes  messages
>
> We want shmid 32769 with 340 bytes.  How can I get it?
>
> [ userid ]$ cd /proc/sysvipc/
> [ userid /proc/sysvipc]$ ls -al
> total 0
> dr-xr-xr-x    2 root     root            0 May 12 12:00 .
> dr-xr-xr-x   54 root     root            0 May 11 09:35 ..
> -r--r--r--    1 root     root            0 May 12 12:00 msg
> -r--r--r--    1 root     root            0 May 12 12:00 sem
> -r--r--r--    1 root     root            0 May 12 12:00 shm
> [logger at mlogger /proc/sysvipc]$ cat sem
>        key      semid perms      nsems   uid   gid  cuid  cgid
> otime      ctime
>          0          0   600          7     0     0     0     0 1305223243
> 1305149770
> [logger at mlogger /proc/sysvipc]$ cat shm
>        key      shmid perms       size  cpid  lpid nattch   uid   gid
> cuid  cgid      atime      dtime      ctime
>          0          0  1600       1808   580   670      3     0     0
> 0     0 1305150844 1305151313 1305149770
>          0      32769  1600        340   580   670      3     0     0
> 0     0 1305150844 1305151313 1305149770
>          0      65538  1600    1728012   580   670      3     0     0
> 0     0 1305150844 1305151313 1305149770
>          0      98307  1600       1220   580  1104      2     0     0
> 0     0 1305150844 1305150844 1305149770
> [logger at mlogger /proc/sysvipc]$ cat msg
>        key      msqid perms      cbytes       qnum lspid lrpid   uid   gid
> cuid  cgid      stime      rtime      ctime
>
> 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:
>
> dd if=/proc/kcore skip=NUMBEROFBYTESTOSKIP bs=340 count=1 of=/tmp/dump
>
> Thanks,
> Jim
>
> --
> Jim Ockers, P.Eng. (ockers at ockers.net)
> Contact info: http://www.ockers.net/msi.html
>
>
> _______________________________________________
> clue mailing list
> clue at cluedenver.org
> http://cluedenver.org/mailman/listinfo/clue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20110512/f73b3b4f/attachment.html