If you create a Xojo.Core.MemoryBlock using Constructor( ptr ) or Constructor( ptr, size ), it cannot be returned properly by a function even though it seems fine in the method that created it.
For example, this does not work properly:
dim mb as new Xojo.Core.MemoryBlock( p, size )
dim mb as new Xojo.Core.MemoryBlock( p )
mb = mb.Left( size )
You will only see the issue when you examine the returned MemoryBlock in the calling method.
Where is the ptr obtained from ?
Thats probably relevant
The pointer in StringToNewMemoryBlock_Fail is automatically “freed” at the end of the function. But I’m not really sure.
Hmm, hadn’t considered that. That makes sense with the vision that takes only a pointer, but what about pointer and size?
I shouldn’t post while standing in line at Starbucks.
The constructor should retain the pointer in any event, no?
Norman, in the example app attached to the Feedback case, I obtained the Ptr from a classic MemoryBlock. As Eli noted, that classic MB goes out of scope at the end of the function that returns the new MB.
so I see
joe will probably need to review this one but he’s out sick today
Spoke to Joe
Not a bug - in fact the new mb CANT take ownership of the Ptr - this is by design
What if it came from a DLL etc ?
We cannot take ownership of whatever memory this ptr points at because something else may own it
You’d need to copy the data to be safe
There may be a case for having a way to create from a Ptr AND copy - but thats not how it works today
So quite literally the memory block goes out of scope & gets deallocated & you have a dangling ptr in Xojo code
Thanks Norman. I’ll keep it in mind.
And now I see that it’s documented that way too. Considering how the rest of my day went, I’m wondering why I even bothered to get out of bed.
Please close the report as by design.