[mapserver-dev] Regarding to the issue: segfault on transparent layers with new renderers (#3834)

[Umberto Nicoletti]

I have an issue open on Java mapscript for the same reason and I am waiting
for a test case from the user.
I can review and test your changes.

Umberto

On Mon, Sep 8, 2014 at 11:46 PM, Lime, Steve D (MNIT) <
Steve.Lime at state.mn.us> wrote:

>  Really need Thomas to weigh in I think… --Steve
>
>
>
> *From:* mapserver-dev-bounces at lists.osgeo.org [mailto:
> mapserver-dev-bounces at lists.osgeo.org] *On Behalf Of *Tamas Szekeres
> *Sent:* Monday, September 08, 2014 2:25 PM
> *To:* mapserver-dev at lists.osgeo.org
> *Subject:* Re: [mapserver-dev] Regarding to the issue: segfault on
> transparent layers with new renderers (#3834)
>
>
>
> Hi Devs,
>
> Regarding to issue #3834 our problem is caused by maintaining a reference
> to the renderer vtable in symbolObj and when the renderer is destroyed
> first, then calling symbolObj->vtable->freeSymbol leads to a crash.
>
>
>
> I've already prepared a patch to use outputFormatObj instead of
> rendererVTableObj which is reference counted and hence it prevents from the
> renderer vtable to be destroyed until the symbol is alive.
>
> However it looks more straightforward for me to rely on the already
> existing renderer_free_func of symbolObj which can contain the pointer to
> the renderer specific cleanup code. In this regard we can call
>  symbolObj->renderer_free_func instead of  symbolObj->renderer->freeSymbol
> and it appears to be safe assuming that renderer_free_func can be called
> even if render->cleanup is called previously.
>
>
>
> We tested this approach and it seems to fix issue #3834. See the changes
> at:
>
>
>
>
> https://github.com/szekerest/mapserver/commit/6a67c37d9c81569a655f7c21fbd48d6123457601
>
>
> Can this fix be applied or anyone can foresee issues with that?
>
> Best regards,
>
> Tamas
>
>
>
>
>
>
>
>
>
> 2014-08-24 18:27 GMT+02:00 Tamas Szekeres <szekerest at gmail.com>:
>
> No comments so far.
>
>
>
> I've prepared a fix to show what I've meant by storing the outputformat
> instead of the renderer vtable in symbolObj.
>
>
>
>
> https://github.com/szekerest/mapserver/commit/f4a4a2831a3d6228181938c0761fa5caf06c6452
>
>
>
> Let me know if such change can be applied in master.
>
>
>
> This change also contains a fix for the memory leaks caused by the
> embedded scalebar and legend symbols which is necessary for making the
> refcount approach to work properly.
>
>
>
> We might also utilize MS_REFCNT macros for the outputformat refcount
> handling too (which are not yet used), but that would involve further
> changes to be made in further files.
>
>
>
> Best regards,
>
>
>
> Tamas
>
>
>
>
>
>
>
>
>
> 2014-08-20 17:42 GMT+02:00 Tamas Szekeres <szekerest at gmail.com>:
>
> Hi Devs,
>
>
>
> Regarding to #3834 <https://github.com/mapserver/mapserver/issues/3834>,
> I can see several hacks in the code attempting to fix the issue, but it
> seems we are still running into the same issue by getting a crash in
> msFreeSymbol at the line:
>
>
>
> s->renderer->freeSymbol(s);
>
>
>
> We've already been discussing about implementing a symbol cache at the
> renderers (and eliminate the need of maintaining back references to the
> renderer at symbolObj), however that seems to require fair amount of coding
> and testing at the first sight.
>
>
>
> What if we change the renderer reference in symbolObj from
> rendererVTableObj to outputFormatObj (which contains the vtable)? Since the
> outputformat is reference counted we could make sure the outputformat (and
> the vtable) exists until the corresponding symbolObj is alive?
>
>
>
>
>
> Best regards,
>
>
>
> Tamas
>
>
>
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140909/042a6286/attachment.html>