1253440 - devtools/client/animationinspector/test TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at Location, mozilla::ipc::MessageChannel::OnMessageReceivedFromLink, OnMessageReceived, mozilla::ipc::ProcessLink::OnMessageReceived

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

For fun, I decided to run ASAN mochitest-dt on Try with e10s enabled and am seeing this permaleak in the animationinspector tests.

https://treeherder.mozilla.org/logviewer.html#?job_id=17571384&repo=try

 14:00:02     INFO -  ==2017==ERROR: LeakSanitizer: detected memory leaks
 14:00:02     INFO -  Direct leak of 160 byte(s) in 10 object(s) allocated from:
 14:00:02     INFO -      #0 0x475061 in __interceptor_malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
 14:00:02     INFO -      #1 0x48dd0d in moz_xmalloc /builds/slave/try-l64-asan-00000000000000000/build/src/memory/mozalloc/mozalloc.cpp:83
 14:00:02     INFO -      #2 0x7f6947934ad6 in Location /builds/slave/try-l64-asan-00000000000000000/build/src/obj-firefox/dist/include/mozilla/mozalloc.h:186
 14:00:02     INFO -      #3 0x7f6947934ad6 in mozilla::ipc::MessageChannel::OnMessageReceivedFromLink(IPC::Message const&) /builds/slave/try-l64-asan-00000000000000000/build/src/ipc/glue/MessageChannel.cpp:765
 14:00:02     INFO -      #4 0x7f6947947e41 in OnMessageReceived /builds/slave/try-l64-asan-00000000000000000/build/src/ipc/glue/MessageLink.cpp:330
 14:00:02     INFO -      #5 0x7f6947947e41 in non-virtual thunk to mozilla::ipc::ProcessLink::OnMessageReceived(IPC::Message const&) /builds/slave/try-l64-asan-00000000000000000/build/src/obj-firefox/ipc/glue/Unified_cpp_ipc_glue0.cpp:331
14:00:02 INFO - #6 0x7f69478d78fa in IPC::Channel::ChannelImpl::ProcessIncomingMessages() /builds/slave/try-l64-asan-00000000000000000/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc:630

Comment 1

[Andrew McCreight [:mccr8]]

That stack is not very good. Somebody would probably have to reproduce locally to get better information.

Comment 2

[Andrew McCreight [:mccr8]]

I'll try to reproduce locally.

Comment 3

[Andrew McCreight [:mccr8]]

The line numbers are basically the same, except it says "operator new" instead of "Location", which makes more sense.

I'm guessing the leaked allocation is the DequeueTask in OnMessageReceivedFromLink:
            mWorkerLoop->PostTask(FROM_HERE, new DequeueTask(mDequeueOneTask));
Note that there are a number of other places in the file that do this exact same thing, with the PostTask and a new DequeueTask, and those are apparently not leaking.

Another bit of information that my local run has is that the frame above ProcessIncomingMessages() is IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking(int).

Comment 4

[Andrew McCreight [:mccr8]]

Attachment: stack from local run

I reproduced this with
  ./mach mochitest -f mochitest-browser-chrome --e10s devtools/client/animationinspector/test/

Comment 5

[Andrew McCreight [:mccr8]]

This needs somebody to dig into the IPC code a bit, and I don't have time for that at the moment.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

David, do you have cycles to pick this up?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Maybe jld? This is 100% reproducible on ASAN builds w/ e10s enabled.

Comment 8

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

I have a build and `./mach mochitest devtools/client/animationinspector` just passed (e10s is the default now).  One difference from comment #4 is that the LLVM/Clang build I used is from a newer version than official Firefox ASan builds, but surely that wouldn't affect a memory leak?

I could also try to redo this with (approximately) the same source revision as comment #4 and see if that makes a difference.  Thoughts?

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] from comment #8)
> I could also try to redo this with (approximately) the same source revision
> as comment #4 and see if that makes a difference.

I tried that.  Still can't reproduce the leak.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Fun story, this was actually fixed the other day by bug 1215265.
https://treeherder.mozilla.org/#/jobs?repo=try&fromchange=3968aad4f5d8&tochange=5126d2eeca77&group_state=expanded&filter-searchStr=dt7