4 ms·

I don't know what the limits are in the nginx HTTP parser You're correct in assuming the library enforces its own size limitations. It operates on length of r

by seiji 15y ago

I don't know what the limits are in the nginx HTTP parser You're correct in assuming the library enforces its own size limitations. It operates on length of received SSL data which is capped by the static receive buffer at 32k. Nice and tiny. (Also, you are, of course, painfully correct about lack of bounds checking and lack of return value checking on the malloc/realloc calls. If I ever graduate the branch to production status, the six malloc calls and three realloc calls will be wrapped in proper checks.)

tptacek 15y ago
For what it's worth, don't check the retval of malloc/realloc/strdup; instead, rig them so they blow up if the allocation fails.
- oconnore 15y ago
  Why? Can't you just bail on whatever you are currently doing? How is the entire process compromised by a failed malloc? Resources are limited, sort of by definition, shouldn't good code be able to handle this possibility?
  - tptacek 15y ago
    If malloc is rigged to explode when it fails, you can't accidentally forget to check; sometimes, malloc failures can end up being exploitable. It's not like most code does anything particularly smart when memory runs out.
    - neilc 15y ago
      An exception to this is library code, which should typically check for malloc failures and return an error to the client code.
  - EdiX 15y ago
    Handling an out of memory error in any way other than terminating the entire process is very very hard, because the effects of memory exhaustion are felt by all your threads at the same time usually preceded by massive slowdown due to swapping (which will cause other symptoms if there is any real time constraints put on the process). I'm not saying there are no cases where recovering from allocation errors would be possible but it's not the general case. It's usually easier to treat any allocation error as a fatal error and insure your programs so they don't run out of memory through other means.

by seiji 15y ago

tptacek 15y ago

For what it's worth, don't check the retval of malloc/realloc/strdup; instead, rig them so they blow up if the allocation fails.

oconnore 15y ago
Why? Can't you just bail on whatever you are currently doing? How is the entire process compromised by a failed malloc? Resources are limited, sort of by definition, shouldn't good code be able to handle this possibility?
- tptacek 15y ago
  If malloc is rigged to explode when it fails, you can't accidentally forget to check; sometimes, malloc failures can end up being exploitable. It's not like most code does anything particularly smart when memory runs out.
  - neilc 15y ago
    An exception to this is library code, which should typically check for malloc failures and return an error to the client code.
- EdiX 15y ago
  Handling an out of memory error in any way other than terminating the entire process is very very hard, because the effects of memory exhaustion are felt by all your threads at the same time usually preceded by massive slowdown due to swapping (which will cause other symptoms if there is any real time constraints put on the process). I'm not saying there are no cases where recovering from allocation errors would be possible but it's not the general case. It's usually easier to treat any allocation error as a fatal error and insure your programs so they don't run out of memory through other means.