0

I have an application running on IRIX which uses m_fork() to create a number of processes. Source code.

When I run the application with 3 forks, everything works as expected. When I ask for four forks, it fails to fork with an "ENOMEM" error:

bash-2.05$ ./hello 3
 Process spawn limit is  8
 Hello world from process 1
 Hello world from process 2
 Hello world from process 0
 2nd line: Hello world from process 1
 2nd line: Hello world from process 2
 2nd line: Hello world from process 0
bash-2.05$ ./hello 4
 Process spawn limit is  8
m_fork() did not work

I know this is a memory allocation issue because when I throw in malloc(900000000); right before m_fork(), everything works as expected.

While this does fix the problem, it's not a suitable solution because it's just an arbitrarily large number. How can I dynamically allocate just enough memory for the forks?

e: The core question I'm trying to get answered here is, "how can I allocate enough memory for the forks?"

Zach Bloomquist
  • 5,309
  • 29
  • 44
  • 1
    Why would burning memory help *avoid* an OOM error? You should investigate that. How could allocating memory and not using it possibly help? – usr Oct 14 '14 at 16:06
  • My impression was that when I malloc the memory, m_fork then uses it for the forks. It does fix the problem though, so it helps. I'm asking the proper way to do it because I realize that's not an appropriate solution. – Zach Bloomquist Oct 14 '14 at 16:11
  • Hi @user3474615, if your claim above is correct, why would 3 procs execute and 4 not without explicit memory allocation? – Myles Baker Oct 14 '14 at 16:12
  • 1
    I'm not sure, do you know? My *guess* is that the first three forks are able to fit within the initial memory allocation, but the fourth one tips the scales. Which is why the malloc "fixes" it. If you look at the source code linked, there is no memory allocation done whatsoever. – Zach Bloomquist Oct 14 '14 at 16:16
  • That doesn't make much sense, but an important thing to realize is that **IRIX m_fork() is quite different than plain unix fork()**. – Chris Stratton Oct 14 '14 at 16:16
  • From the m_fork() man page (http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat3p/m_set_procs.z) The processes are created using the sproc(2) system call, and share all attributes (virtual address space,file descriptors, uid, etc.). Check out the fourth paragraph of sproc(2) below. I think this holds the answer, but I don't have an IRIX machine I can test this on. Good luck! http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=getdoc&coll=0650&db=man&fname=2%20sproc – Myles Baker Oct 14 '14 at 16:23
  • 1
    fork cannot use random application memory for its purposes. You might be using that memory. This theory is false. – usr Oct 14 '14 at 16:27
  • @usr, can you offer an alternative explanation as to why it works with the large malloc call? – Zach Bloomquist Oct 14 '14 at 16:33
  • @MylesBaker thanks for the pointer. I'll check it out some more, although strace shows the system call as being a regular sproc call. Not sure if I can affect the arguments to that too much. – Zach Bloomquist Oct 14 '14 at 16:34
  • No, because I know almost nothing about fork. But I can show that the existing theory is not right. – usr Oct 14 '14 at 16:41
  • @usr, please do. I'm very new to C and I don't have a solid grasp of memory. – Zach Bloomquist Oct 14 '14 at 16:59
  • `printf("m_fork() did not work \n")` is not very informative. Print `strerror(errno)` instead. – user58697 Oct 14 '14 at 17:28
  • @user58697, as described in the problem it is an ENOMEM error. – Zach Bloomquist Oct 14 '14 at 17:47

0 Answers0