Ticket #1101 (closed bug: fixed)

Opened 4 years ago

Last modified 3 years ago

Potential memory corruption caused by faulty cloning of ResizableFloatArray

Reported by: kurahaupo Owned by:
Priority: normal Milestone:
Component: core Version: trunk
Severity: high Keywords: memory corruption
Cc: Language:
Patch status: applied Platform: all

Description

Code inspection revealed that clone sets the resize_threshold not on the new PMC, but on the old one.

The new PMC has only just enough memory to hold the number of elements, yet when resized within the resize_threshold of the original PMC, could be logically resized without actually reallocating memory. Later updates to elements in the extended range could overwrite unrelated memory.

Attachments

memory-corruption-by-resizablefloatarray.patch Download (460 bytes) - added by kurahaupo 4 years ago.
Patch to repair problem

Change History

Changed 4 years ago by kurahaupo

Patch to repair problem

Changed 4 years ago by kurahaupo

Just to clarify: the resize_threshold in the new object is left unset.

If it's placed in virgin memory, it will be zero, which is harmless.

However if it's in recycled memory, it will hold whatever garbage was left by the previous object that occupied that memory. Subsequent logical resizing would then trigger this bug.

(I'm assuming of course that new PMC doesn't zero its attribute memory. If you know whether that's true or not, please update this ticket.)

Changed 3 years ago by NotFound

  • status changed from new to closed
  • resolution set to fixed
  • patch changed from new to applied

RFA uses auto_attrs, which zeroes the attributes. However I think the fix is good, having an inappropriate threshold in original or in clone is no good. Applied in r45990

Note: See TracTickets for help on using tickets.