UNIX for Advanced & Expert Users

I'm experiencing some strangeness when using plock().

I'm on a Solaris 5.7/SPARC machine with 64MB of memory.

I can show that plock() works by successfully locking down 10 MB of memory.

Then, I ask for 40 MB, and I get a failure notice because there is "Not enough memory" available.

I then try to get 10 MB again, and get the same "Not enough memory" failure.

Why doesn't the 10 MB lock down the second time?
I have freed everything, the memory should be available again.

Here's a link to the source code... any ideas?

http://www.wegotitall.com/user_space/troccola/plock.c

Thanks!

First, a process's memory is divided into pieces called segments. There is a text segment and a code segment which are required to exist by standards and there may be others. malloc() allocates free space at the end of the data seqment. If there isn't enough free space, malloc will use the sbrk() system call to add space. Thus malloc can and usually does make a process grow. free() on the other hand will never shrink a process. It just adds the area being freed to the space available for subsequent malloc() calls.

Next, plock(PROCLOCK) attempts to lock the entire text and data seqments into core. Looking at your post and your code, I gather that you think the plock(PROCLOCK) somehow will only lock whatever the last malloc() call allocated. plock() doesn't know or care about malloc(), it operates on entire segments.

So your program first malloc'ed 10MB which increased the size of your process by about 10MB. At this point, plock(PROCLOCK) worked. Then you freed the area and malloc'ed 40MB. Well you get use the spare 10MB that you freed, but malloc() must increase your process by another 30MB to satisfy the request. At this point, your process is now too big to be locked into memory. It stays too big when you do the free(). It won't need to grow as you malloc the final 10MB, it just allocates 10MB from the 40MB that you freed. But it still can't be locked.

OK, I see exactly what you mean. I think you are correct.

However, I'm not out of the woods just yet.

From the sbrk man page, I found that...

sbrk adds incr bytes to the break value and changes the allocated space accordingly. incr can be negative, in which case the amount of allocated space is decreased.

So, with intentions of "shrinking" the process size, I've added

sbrk(-1 * MB_to_lock * MEGABYTE);

to my code immediately following the plock call that fails.

Unfortunately, with the sbrk call, the very next malloc now causes a SEGV. I don't understand why.

Assuming my process size is N bytes to start, shouldn't it change like this?

Start up : N bytes
After lock(10) : N + 10 MB
After free(10) : N + 10 MB ( free doesn't shrink process size )
After lock(40) : N + 40 MB
After free(40) : N + 40 MB ( free doesn't shrink process size )
After sbrk(-40 MB ) : N ( sbrk -40MB should shrink process sz)

Am I missing something?

Thanks in advance,
T

Like I said malloc/free will never shrink the process. But also, they aren't prepared for you to sneak in and do it for them. So malloc() is assuming that the process is still the same size it left it. And when it tries to reference the now non-existant space that it previously allocated, you get a SIGSEGV.

So, in a nutshell, there's no way to shrink the process size again.

Yow! I didn't mean to imply that. There is no way to shrink the data segment if you are using the standard malloc and free routines. To be more accurate, there is no way to shrink the data segment's virtual size. If you lay off plock(), the kernel will happily grow and shrink its physical size as required. (And by the way, repeatedly locking and unlocking segments as you are doing is guaranteed to devastate system performance if memory is tight.)

Also, you can call sbrk() directly. There is a nasty can of worms here. The direction in which the heap grows is undefined. It may grow in the same direction as the stack. Or it may grow in the reverse direction. So when you allocate a buffer you may need to return a pointer to the first new byte or the last new byte. This can change from system to system. So you will want your own routine that sits on top of sbrk to hide the idiosyncrasies of pointer arithmetic from the application. And be aware that this routine cannot be written portably.

And using the stack is another way processes grow and then shrink. Automatic variables spring into existence when a function is called and vanish when it returns.