track_event coredump about perfetto HOT 13 CLOSED

I think it's a compatibility problem. Old commit works well

from perfetto.

How to recurrent it:
use gapid(master branch newest code) and capture trace with systemprofile and config: vulkan track memory. The gapis will coredump becauseof this pro blem.
Use release gapid 1.7 it woks well because using old version

from perfetto.

@tilal6991 can you take a look?

@official-minister can you attach a trace file (instead of text dump)? It would help a lot.
We don't ahve a good way to go back from the text dump to the file to feed in trace processor

from perfetto.

Sorry I can't push trace file for some reason. I just can write trace txt here.
I described the situation how to recurrent it.

I avoid the proplem by doing this:
src\trace_processor\importers\proto\track_event_parser.cc
// Parse process and thread names from correspondingly named events.
NullTermStringView event_name = storage->GetString(name_id_);
//PERFETTO_DCHECK(event_name.data());
if(!event_name.data()) {
return util::OkStatus();
}_

But I think it's not the root cause. I hope it will help you analysis the problem.

from perfetto.

I took a look and I think returning ok when event_name is null is not the right solution.

@betasheet can you see anything wrong with the data in the trace? Seems from the code that name_id_ is being set to null id which should never happen.

from perfetto.

I took a look and I think returning ok when event_name is null is not the right solution.

@betasheet can you see anything wrong with the data in the trace? Seems from the code that name_id_ is being set to null id which should never happen.

I agree with your opinion. I'm confused why name_id_ is null.

from perfetto.

Maybe the trace doesn't set the SEQ_INCREMENTAL_STATE_CLEARED flag?

In terms of the crash - good question. Maybe the early out should also check for name being the empty string, in addition to kNullStringId?

from perfetto.

Talking about this early-out: https://source.chromium.org/chromium/chromium/src/+/master:third_party/perfetto/src/trace_processor/importers/proto/track_event_parser.cc;l=681?q=track_event_parser.cc:644

FWIW, the packet should really also be setting SEQ_NEEDS_INCREMENTAL_STATE as it is using incremental state. In that case, it would likely be discarded during tokenization.

How did you generate this trace?

from perfetto.

Re the crash: the string is actually null not empty (this is why the crash happens) which means the early return is not being hit correctly (https://source.chromium.org/chromium/chromium/src/+/master:third_party/perfetto/src/trace_processor/importers/proto/track_event_parser.cc;l=680?q=track_event_parser.cc:644)

from perfetto.

@official-minister it would be really helpful if you could share the trace so I could repro this behaviour. Seems a pretty bad bug going on.

The easiest way to share a trace if Github doesn't allow it to be uploaded is to use something like Google Drive/Dropbox and share the link ehre.

from perfetto.

Sorry I can't upload file because of net environment. I can tell you how I get it.
I use gaid(master branch) code: (1.7 release works no bug.)
https://github.com/google/gapid
and complie it follow this:
https://github.com/google/gapid/blob/master/BUILDING.md
and I start trace with vulkan memory track. It will generate it.

Maybe you can refer to : google/agi#334

from perfetto.

I don't have the cycles to try and get AGI compiling on my Mac unfortunately (I did try but I ran into errors which I didn't look into further). If I manage to get a trace (either from yourself or the AGI folk), I'd be happy to look into this but otherwise, I am putting this on pause.

from perfetto.

Closing this issue as it's essentially unactionable as is and there's been a lot of changes in AGI <-> Perfetto integration since this bug was opened.

from perfetto.