Why we have shared Memory Corruption ?

Solution Unverified - Updated -

Issue

  • Application Framework uses a Shared Memory region to store global information for use by all application processes.

  • The region is approximately 4 MB and split into two parts with an 8k header and the remainder used for locks. The shared memory is allocated using the using the shmget()/shmat01263279() system calls, all processes attach to this region in READ/WRITE mode.

  • As a consistency check, when the process attaches to the existing shared memory, it checks the “revision” field, this is currently set to 1 (as it has always been), if this values is not 1, then the process will exit with the error indicating that the revision is wrong.

  • The application has recently encountered cases when this shared memory appears to become corrupt, which prevents the application processes from staring up. This causes a major operational problem whereby the application needs to be taken down, the shared memory removed, reinstated and the application restarted.

  • It has been noticed that the Virtual Address returned by mmap, and shmat are very similar

Environment

  • Red Hat Enterprise Linux 5.5

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.