Hi Stephane,
On 2017-01-26 14:51:02 -0800, Stephane Eranian wrote: > Ok, I think I see the problem now (sorry was slow....): No worries ;) > the timeline is as follows as seen from the user in your case: > > T0: mmap(0x1000) for func1() > T1 mmap(0x2000) for func1(); > T3: jit emits info func1() [0x1000-0x1fff] > T4: mmap(0x3000) for func2() > T5: mmap(0x4000) for funcs2() > T6: jit emits info for func2() [0x2000-0x3fff] > > But the problem is that each mmap covers existing mmaps and thus > supersedes the others as per the time stamp. Yes, I think that's whats happening. Not that I actually know what I'm talking about here :) > The problem is not specific to jit, it just reveals itself in your case. > > The logic in perf is that a more recent mmap supersedes an older one, > so you have: > T3: 0x1000-0x2000 owned by func1 > T4: 0x1000-0x3000 owned by anon > T5: 0x1000-0x4000 owned by anon > T6: 0x1000-0x4000 owned partially by func2() > > And thus perf cannot symbolize func1() anymore because it has nothing > mapped in 0x1000-0x1fff but anon. > > Did I get the problem right this time? Yep. > This is tricky to solve here because the tool does not know about the > merging of the VMAs and assume you are overlapping mmaps and not > merging them. Yea, it looked tricky. I'd looked around and the only solutions I'd found was filtering out the anon mappings (obviously not a real solution) or preventing the merging (not a real solution either). > Again the problem is not specific to jit, merging of VMA can happen > anytime with any app. Sorry if I hinted in the wrong direction - I didn't see any other bad consequences. I guess in most other cases with merged VMAs its relatively harmless, since it'll presumably mostly be memory allocations and such, where this wont matter. Greetings, Andres Freund
