[mapserver-commits] [mapserver/mapserver] bbe23e: oracle - fixing memory handling error
GitHub
noreply at github.com
Tue Jan 17 02:26:47 PST 2017
Branch: refs/heads/branch-7-0
Home: https://github.com/mapserver/mapserver
Commit: bbe23e8c0b9cce174dc3ff313e3e5d3560c1e62b
https://github.com/mapserver/mapserver/commit/bbe23e8c0b9cce174dc3ff313e3e5d3560c1e62b
Author: Pierre Mauduit <pierre.mauduit at camptocamp.com>
Date: 2017-01-17 (Tue, 17 Jan 2017)
Changed paths:
M maporaclespatial.c
Log Message:
-----------
oracle - fixing memory handling error
If the memory area pointed by table_name is too small, it is resized
multiplying its size by 2. But if this occurs, the tgt variable used in
the "for" loop continues to point on a memory area which might have become
invalid (because the realloc could have moved the memory somewhere else,
depending on how the OS manages the memory).
To fix this, in my understanding, the tgt pointer should be readjusted
to the new location pointed by table_name.
Running valgrind without my patch (sources based on the 7.0.1 version,
but the maporaclespatial.c is identical to master):
==1908== Invalid write of size 1
==1908== at 0x4E81FEF: msSplitData (in /usr/lib/x86_64-linux-gnu/libmapserver.so.7.0.1)
Tests: runtime tested in a docker composition
Note: valgrinds continues to indicate some errors related to this msSplitData()
method:
==1945== 32,000 bytes in 1 blocks are definitely lost in loss record 264
of 268
==1945== at 0x4C2AF2E: realloc (vg_replace_malloc.c:692)
==1945== by 0x4EBDF4B: msSplitData (maporaclespatial.c:404)
==1945== by 0x4EC90E0: msOracleSpatialLayerTranslateFilter (maporaclespatial.c:3499)
I wonder if in the context of msOracleSpatialLayerTranslateFilter(),
the pointers are still valid when they are actually freed at the end of
the method.
More information about the mapserver-commits
mailing list