Re: fork bug [WAS: Re: "mount" bug]

[Harry Kalogirou <harkal@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

> On 26 Oct 2002, Harry Kalogirou wrote:
> 
> > "Cannot fork" is emmited by the shell, when the fork() system call
> > fails. The system call will fail :
> > 
> > 1) If there are no more process slots available.
> > 2) There is not enough free memory.
> > 
> > What exacly happend there, I realy can't tell. The only thing I can tell
> > is that something "very" bad happed there. I personaly havedn't seen
> > ELKS behave like that before. 
> 
> There appears to be a bug in the "get_pid()" function from fork.c. The 
> code fragment:
>     if (++last_pid == 32768)
>         last_pid = 1;
> must eventually fail because last_pid is declared as type pid_t, which is 
> typedef'ed as __s16, which is in turn typedef'ed as signed short int. 
> Since signed 16-bit numbers roll over from 32767 to negative numbers, they 
> can never equal 32768. A possible fix might be:
>     if ( (++last_pid && 0x7fff) == 0 )
>         last_pid = 1;
> or, perhaps smaller and faster:
>     if !( (last_pid++) &= 0x7fff )
>         last_pid++;
> The latter may have superfluous parentheses because I'm not sure of the 
> precedence, and whether "variable++" is smaller and faster than 
> "++variable" is probably compiler-dependent.
> 

Commited...

Harry



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]