Closed jc00ke closed 5 years ago
thanks for reporting -- I'm pretty sure what is happening here is that both chrome + firefox bundle their own allocators by default, and overriding malloc/free causes a pointer to be allocated from mesh and e.g. returned to tcmalloc (or the other way around).
I wonder if we can detect this and bail early, maybe if the RTLD_NEXT
malloc
symbol isn't from libc
?
Interesting. Maybe I missed it in the paper, but did you compile Firefox with mesh
as the allocator? I was under the impression that the LD_PRELOAD
env var would swap out allocators.
What I'm really hoping for is LD_PRELOAD=libmesh.so slack
:wink:
@jc00ke we compiled firefox with the --no-jemalloc
option; otherwise firefox (for performance reasons) uses jemalloc in such a way that it is non-overridable via LD_PRELOAD
. Slack is going to have a similar problem I suspect (as Chromium defaults to a similar thing)
@bobby-stripe gotcha, thanks for the clarification. I guess it makes sense to close this for now.
Using 667bb69 compiled on Manjaro with
gcc 8.2.1 20181127
. Any other details I can provide that would be helpful?I also tried running Chromium and got a segfault as well: