<div dir="ltr"><div>The real root cause is a plain old overflow bug in ksh, happening at that line:</div> <a href="https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/jobs.c#L1869">https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/jobs.c#L1869</a><div><br></div><div>because of the way the BYTE macro has been written:</div><div> <a href="https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/jobs.c#L101">https://github.com/att/ast/blob/master/src/cmd/ksh93/sh/jobs.c#L101</a><br></div><div><br></div><div>Check this small example:</div><div><br></div><div><div>#include <stdio.h></div><div>#include <limits.h></div><div><br></div><div>#define BYTE(n) (((n)+CHAR_BIT-1)/CHAR_BIT)</div><div><br></div><div>int main()</div><div>{</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>int i = BYTE(INT_MAX);</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>printf("i = %d\n", i);</div><div>}</div></div><div><br></div><div>and here is what clang warns about when you try to compile it (both 64bit and 32bit give the exact same result):</div><div><br></div><div><div>test.c:8:10: warning: overflow in expression; result is -2147483641 with type 'int' [-Winteger-overflow]</div><div> int i = BYTE(INT_MAX);</div><div> ^</div><div>test.c:4:30: note: expanded from macro 'BYTE'</div><div>#define BYTE(n) (((n)+CHAR_BIT-1)/CHAR_BIT)</div><div> ^</div><div>1 warning generated.</div></div><div><br></div><div>and when you execute it, you get:</div><div><br></div><div>i = -268435455<br></div><div><br></div><div>In the end, the fact that BYTE() returns a negative value completely messes up the logic in job_alloc() that doesn't guard against that. From there on, hell starts freezing over and ksh misbehaves randomly as it believes it cannot allocate a job while it did.</div><div><br></div><div>After all, my opinion is that there's no bug in LX, no bug in OmniOS, but defaulting to INT_MAX for <span style="font-size:12.8px">zone.max-lwps is IMHO a mistake. It sounds more logical to me to default to the global zone's value of </span><span style="font-size:12.8px">sysconf(_SC_CHILD_MAX).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">--</span></div><div><span style="font-size:12.8px">Ludovic</span></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 4:33 PM, Michael Rasmussen <span dir="ltr"><<a href="mailto:mir@miras.org" target="_blank">mir@miras.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 11 May 2017 11:11:14 +0200<br>
Ludovic Orban <<a href="mailto:lorban@bitronix.be">lorban@bitronix.be</a>> wrote:<br>
<br>
><br>
> Apparently, ksh isn't very happy when CHILD_MAX equals to MAX_INT, but<br>
> that's probably a ksh bug.<br>
><br>
</span>Could it be ksh interprets int as it was defined in the 32bit OS days<br>
int = 16bit = INT_MAX 32767 and expecting to receive a signed<br>
int?<br>
<br>
This is obviously wrong since ISO/IEC 9899 only requires an int to be<br>
at least 2^16 - 1. INT_MAX is defined in limits.h<br>
<br>
--<br>
Hilsen/Regards<br>
Michael Rasmussen<br>
<br>
Get my public GnuPG keys:<br>
michael <at> rasmussen <dot> cc<br>
<a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E" rel="noreferrer" target="_blank">http://pgp.mit.edu:11371/pks/<wbr>lookup?op=get&search=<wbr>0xD3C9A00E</a><br>
mir <at> datanom <dot> net<br>
<a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C" rel="noreferrer" target="_blank">http://pgp.mit.edu:11371/pks/<wbr>lookup?op=get&search=<wbr>0xE501F51C</a><br>
mir <at> miras <dot> org<br>
<a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917" rel="noreferrer" target="_blank">http://pgp.mit.edu:11371/pks/<wbr>lookup?op=get&search=<wbr>0xE3E80917</a><br>
------------------------------<wbr>------------------------------<wbr>--<br>
/usr/games/fortune -es says:<br>
Witch! Witch! They'll burn ya!<br>
-- Hag, "Tomorrow is Yesterday", stardate unknown<br>
<br>______________________________<wbr>_________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com">OmniOS-discuss@lists.omniti.<wbr>com</a><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" rel="noreferrer" target="_blank">http://lists.omniti.com/<wbr>mailman/listinfo/omnios-<wbr>discuss</a><br>
<br></blockquote></div><br></div>