[Date Prev][Date Next]
Re: (ITS#4689) sladp - glibc - double free or corruption when searching translucent overlay
> OK, that's rwm not translucent. What I suspect is that slapo-rwm(5)
> occasionally does something nasty with memory: it deletes what's passed by
> the caller and replaces it with its own massaged data. Apparently,
> translucent is passing it a temporary Operation structure, and rwm
> modifies some of its content, but the caller, do_search() in this case,
> sees a dangling pointer because rwm freed and replaced it with a newly
> allocated one that's now leaked.
> slapo-rwm(5) in general needs some redesign; in fact, it was designed to
> act like that because at that time there was no sc_cleanup handler in
ok. so you mean that this wont be fixed any time soon? or did i
is there a workaround when using rwm with translucent?
thanks for your help.