Ticket #281 (closed Defect: fixed)

Opened 2 years ago

Last modified 3 months ago

lib/mfile.C should consider "buf" still exists when realloc()==NULL

Reported by: Joses Assigned to: davea
Priority: Undetermined Milestone: Undetermined
Component: Client - Build Version:
Keywords: Cc:

Description

Please consider the attached file as "highlighting" or "suggesting" fixes for existing realloc() functions since the actual code shown is untested.

Just a note: If realloc() finds out it doesn't have enough memory to do what needs to be done it returns the value NULL (but the existing memory buffer still exists).

Reason for suggesting this enhancement is due to experience with plenty of other programs which don't take NULL into account (this becomes a bit of a problem with computers that have limited RAM computers and limited or (worse) no SWAP space).

Attachments

mfile.C.diff (1.9 kB) - added by Joses on 06/16/07 00:42:58.
highlight several realloc() functions that should handle existing "buf"
parse.C.diff (453 bytes) - added by Joses on 06/16/07 01:20:35.
lib/parse.C has a similar problem - highlighted realloc()==NULL

Change History

06/16/07 00:42:58 changed by Joses

  • attachment mfile.C.diff added.

highlight several realloc() functions that should handle existing "buf"

06/16/07 01:20:35 changed by Joses

  • attachment parse.C.diff added.

lib/parse.C has a similar problem - highlighted realloc()==NULL

12/05/07 11:56:53 changed by romw

  • owner changed from romw to davea.

06/03/09 14:11:29 changed by davea

  • status changed from new to closed.
  • resolution set to wontfix.

It's not clear what problem this fixes

06/03/09 14:14:35 changed by Nicolas

If realloc() fails, BOINC loses the pointer to the original buffer, causing a leak, making the lack-of-memory problem worse.

06/03/09 19:37:06 changed by Joses

  • status changed from closed to reopened.
  • resolution deleted.

I would consider this just one of the fixes to help harden BOINC a bit more for fault tolerance (especially for machines that have little memory and are misconfigured (especially without any sort of swap file like I've seen on some older linux distros - netbooks could be an example of machines short on memory - and other attributes as well where some sort of sanity check would be of benefit)).

I've seen the number of complains on OpenOffice?'s hunspell drop due to fixes like these (check bugfix #1749709 on sourceforge as an example), and similar alloc and realloc patches for aspell. Realloc is a bit tougher to notice but is fixable too - however, I don't know your preferred stategy with dealing with errors so I left that up to you (I prefer returning stuff back through the stack).

There are also several IO routines that could benefit from some error checks as well, but from experience, it's best to release a few bugs at a time instead of sending in an overwhelming large number of patches - this realloc() being one of several improvement hopefully accepted :-)

07/10/09 15:59:47 changed by davea

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [18594]) - client: if malloc fails in MFILE writes, exit.

We don't check the return values of printf() anywhere, and it's dangerous for the client to continue if it thinks something got written that didn't. Fixes #281

If this page is incomplete or incorrect, please edit it or add it to the wiki to-do list. To do this, you must be logged in; click Login or Register above.