Changes between Initial Version and Version 1 of Ticket #10334, comment 3


Ignore:
Timestamp:
Dec 22, 2013 1:50:27 AM (6 years ago)
Author:
anevilyak
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #10334, comment 3

    initial v1  
    11The problem relates to DWARF4 implicit values, seemingly the build scripts for libusbx force the use of that version of the standard, as that isn't yet gcc's default. In any case, what occurs here specifically is that copies of the ValuePieceLocation are made via operator= when adding it to an Array. As this only does a shallow copy by default, both pieces wind up having a pointer to the same heap allocated memory block, and consequently when the original goes off the stack, it frees said pointer, leaving the other in the array pointing to already freed memory.
    22
    3 Attached is a patch that overrides the = operator to force a malloc + memcpy in that circumstance, but I'm not entirely happy with that solution, since it doesn't readily allow detection of out of memory conditions without introducing exception handling. My initial thought was to instead introduce a new BReferenceable subclass specifically for storing implicit value data, and then have ValuePieceLocation simply store a reference to such an object rather than a void pointer, so that the assignment operator would simply add a reference and deal with it from there.  However, this is problematic due to ValueLocation's use of the Array class for storing its pieces. The latter uses malloc/memcpy/memmove to manage its internal array, and consequently doesn't actually wind up calling object constructors for its templated type. This in turn leads to a crash here, since this means it calls our overridden operator= on an uninitialized block of memory, and in turn, its member BReferenceable has an invalid pointer that it thinks it must release before assigning the new reference. If the Array class is generally intended to be used with C++ objects, that behavior seems suboptimal, but I'm uncertain as to the best way to fix it. Any thoughts/alternative suggested approaches?
     3Attached is a patch that overrides the = operator to force a malloc + memcpy in that circumstance, but I'm not entirely happy with that solution, since it doesn't readily allow detection of out of memory conditions without introducing exception handling. My initial thought was to instead introduce a new BReferenceable subclass specifically for storing implicit value data, and then have ValuePieceLocation simply store a reference to such an object rather than a void pointer, so that the assignment operator would simply add a reference and deal with it from there.  However, this is problematic due to ValueLocation's use of the Array class for storing its pieces. The latter uses malloc/memcpy/memmove to manage its internal array, and consequently doesn't actually wind up calling object constructors for its templated type. This in turn leads to a crash here, since this means it calls our overridden operator= on an uninitialized block of memory, and in turn, its member BReference has an invalid pointer that it thinks it must release before assigning the new reference. If the Array class is generally intended to be used with C++ objects, that behavior seems suboptimal, but I'm uncertain as to the best way to fix it. Any thoughts/alternative suggested approaches?