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