Could anyone point me towards further ways to debug a problem I'm having?

Are there any dtrace probes or debugger modules that might help me to
determine where and why in the kernel an ENOMEM is being returned from
brk(2)?


We have a zone on which we run a third party broker service (circonus
broker). I need to update to a newer version of the broker, so I'm trying
provisioning a new zone in which to do so.

When the process reaches around 280M RSS, a brk() receives an ENOMEM (as
seen by truss), which the process catches, then exits. There is around 3G
free memory at this time. I don't see any limits in ulimit or in prctl that
correspond to this number. I've even tried running the process in a project
with basic and priv values at close to maximum... same problem at 280M.

brk(2) suggests this could be because setrlimit(), which is only ever
called in the process for RLIMIT_NOFILE. `swap -l` shows 15G free. The
process does use mmap in places, though I only see the errors with malloc
and realloc as far as I can tell.

Thank you in advance!

-- 
----
e s



-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Reply via email to