lkml.org 
[lkml]   [1998]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectAny known 2.0.33 problems with shared memory segments?
    Are there any known problems with Linux-2.0.33 (or maybe RedHat 5.0)
    and using shared memory?

    We had a project runnins on RedHat 3.2 and Linux 2.0.21 that ran fine
    but now since "upgrading" to RedHat 5.0 and v2.0.33 we are having problems
    namely we are trying to allocate 4 seperate shared memory segments and
    we are only being allowed to create two. The other requests fail and
    set errno to 17.

    We didn't change anything on our side so we were wondering if there is
    known bug, or change to the shared memory stuff?

    Any ideas? when showing "ipcs" we get this...

    ------ Shared Memory Segments --------
    key shmid owner perms bytes nattch status
    0x00001f40 257 nobody 777 1079344 6160
    0x00001e14 386 garden 777 250012 9682

    ------ Semaphore Arrays --------
    key semid owner perms nsems status
    0x00002004 0 nobody 777 1
    0x00002002 1 nobody 777 1
    0x00002006 258 garden 777 1
    0x00002005 259 garden 777 1
    0x00002003 4 nobody 777 1
    0x00002001 5 nobody 777 1
    0x00002000 6 nobody 777 1
    0x00001b58 519 garden 777 1
    0x00001b59 520 garden 777 1

    ------ Message Queues --------
    key msqid owner perms used-bytes messages

    But it seems weird to us that the number of attached segments is 6160,
    sometimes as high as 40000. We certainly haven't created that many
    processes that could have attached to that memory segment.

    strange... Anybody know why?

    - Jeff Wiegley

    \
     
     \ /
      Last update: 2005-03-22 13:41    [W:0.022 / U:0.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site