Thanks for your feedback but I did it intentionnaly in order to illustrate
that original data (from old pointer) change when we reallocate. My
undestanding was that realloc doesn't change the original data and if
pointer change you have to copy old data to the new pointer.
Here is the typescript side
const newPtr = (<EmscriptenModuleExtended>this._module)._realloc(
ptr,
newLength * Uint32Array.BYTES_PER_ELEMENT
);
const newPtrBuffer = new Uint32Array(
this._module.HEAP8.buffer,
newPtr,
newLength
);
if (newPtr !== ptr) {
const length = this.metas[1];
if (copyBufferIfPtrChanged) {
//console.log('ptr changed',this._ptrBuffer);
newPtrBuffer.set(
newLength < length ? this._buffer.slice(0, length) : this._buffer
);
}
console.log('newPtrBuffer : ', newPtrBuffer);
this.metas[2] = newPtr;
}
this.metas[1] = newLength;
this._buffer = newPtrBuffer;
Le lundi 11 novembre 2019 12:26:48 UTC+1, Floh a écrit :
>
> Your test program doesn't reassign 'val' to the new pointer returned by
> realloc(), so in the second printf() you're actually reading from the old
> (not the reallocated) memory location.
>
> If you change the function like this it should work as expected:
>
> EMSCRIPTEN_KEEPALIVE void* _realloc(void* ptr, size_t size){
> unsigned int* val = ptr;
>
> printf("before %i %i %i %i %i %i \n", val[0], val[1], val[2], val[2],
> val[4], val[5]);
> void* newPtr = realloc(ptr,size);
> val = newPtr;
> printf("after %i %i %i %i %i %i \n", val[0], val[1], val[2], val[2],
> val[4], val[5]);
> return newPtr;
> }
>
> Reason's why this code may appear to work on native platforms could be:
>
> - realloc() is allowed to grow the memory "inplace" and return the same
> pointer, but this behaviour isn't guaranteed, one should always assume that
> a new pointer is returned
> - or realloc() might actually return a new pointer, but you're reading
> from freed memory, and this only has the same content because nobody else
> has overwritten it yet (this sort of bug can be caught with memory
> debugging tools like clang address sanitizer, Valgrind or Dr.Memory.
>
>
> On Monday, 11 November 2019 09:15:29 UTC+1, Gilles Boisson wrote:
>
>> Hello,
>>
>> I was playing around malloc / realloc to create dynamic buffer accessible
>> from JS, and I realized that realloc change my data inside when the
>> returned pointer change .
>> I'm not a libc expert but i thought realloc doesn't affect data itself.
>>
>> I did a proxy method for debugging and validate the fact that the realloc
>> change data.
>>
>> EMSCRIPTEN_KEEPALIVE void* _realloc(void* ptr, size_t size){
>> unsigned int* val = ptr;
>>
>> printf("before %i %i %i %i %i %i \n", val[0], val[1], val[2], val[2],
>> val[4], val[5]);
>> void* newPtr = realloc(ptr,size);
>> printf("after %i %i %i %i %i %i \n", val[0], val[1], val[2], val[2],
>> val[4], val[5]);
>> return newPtr;
>> }
>>
>>
>> Here is my makefile
>>
>> BUILD = emcc
>> LINK = emcc
>>
>> SRC_DIR = src
>> BUILD_DIR = dist
>> OBJ_DIR = obj
>>
>> LINK_FLAGS = -O3 -s STANDALONE_WASM -s NO_EXIT_RUNTIME=1 -s
>> EXTRA_EXPORTED_RUNTIME_METHODS='["ccall","cwrap"]' -s
>> EXPORTED_FUNCTIONS='["_malloc","_free"]'
>> BUILD_FLAGS = -c -O3
>>
>> PROJECT_NAME = em_app
>>
>>
>> SOURCES = $(wildcard $(addprefix $(SRC_DIR)/,*.c)) $(wildcard $(addprefix
>> $(SRC_DIR)/glmatrix/,*.c))
>> OBJECTS = $(SOURCES:$(SRC_DIR)/%.c=$(OBJ_DIR)/%.o)
>>
>>
>> all: $(PROJECT_NAME)
>>
>>
>>
>>
>> $(PROJECT_NAME): $(OBJECTS)
>> $(LINK) $(OBJECTS) -o $(addprefix $(BUILD_DIR)/,$@.js) $(LINK_FLAGS)
>>
>>
>> $(OBJ_DIR)/%.o: $(SRC_DIR)/%.c
>> $(BUILD) $< -o $@ $(BUILD_FLAGS)
>>
>> clean:
>> rm -f $(addprefix $(BUILD_DIR)/,$(PROJECT_NAME).js) $(addprefix
>> $(BUILD_DIR)/,$(PROJECT_NAME).wasm) $(OBJECTS)
>>
>>
>> Any chance to have your lights on the subject.
>>
>> Cheers,
>>
>>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/47c2fbe8-d858-4039-88e2-c89b041aea9e%40googlegroups.com.
