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.035 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site