Unable to use the "seek" runner

[keenua]

Hey,

I'm trying to run the "Seek" example. But it seems to get stuck after the very first runner.seek(nextTick) call.

This is the exception trace I'm getting:

---START--- Exception in thread "clarity-runner" java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: Baseline for class CWorld (696) not found. at skadistats.clarity.event.Event.raise(Event.java:25) at skadistats.clarity.processor.runner.AbstractFileRunner.initAndRunWith(AbstractFileRunner.java:23) at skadistats.clarity.processor.runner.ControllableRunner$3.run(ControllableRunner.java:207) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: Baseline for class CWorld (696) not found. at skadistats.clarity.event.Event.raise(Event.java:25) at skadistats.clarity.processor.reader.InputSourceProcessor.processSource(InputSourceProcessor.java:139) at skadistats.clarity.event.AbstractInvocationPoint.invoke(AbstractInvocationPoint.java:72) at skadistats.clarity.event.Event.raise(Event.java:23) ... 3 more Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Baseline for class CWorld (696) not found. at skadistats.clarity.event.Event.raise(Event.java:25) at skadistats.clarity.processor.reader.InputSourceProcessor.processEmbedded(InputSourceProcessor.java:248) at skadistats.clarity.event.AbstractInvocationPoint.invoke(AbstractInvocationPoint.java:72) at skadistats.clarity.event.Event.raise(Event.java:23) ... 6 more Caused by: java.lang.RuntimeException: Baseline for class CWorld (696) not found. at skadistats.clarity.processor.entities.Entities.getBaseline(Entities.java:235) at skadistats.clarity.processor.entities.Entities.onPacketEntities(Entities.java:154) at skadistats.clarity.event.AbstractInvocationPoint.invoke(AbstractInvocationPoint.java:72) at skadistats.clarity.event.Event.raise(Event.java:23) ... 9 more ERROR: transport error 203: Timed out waiting for connection JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal error [transport.c:326] ERROR: transport error 203: Timed out waiting for connection JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal error [transport.c:326] ---END OF EXCEPTION---

This is the replay I'm testing on: 2626915181.

The "Info" example works just fine on the same replay. The "Tick" example crashes after 7000 ticks or something as well, but I guess this is a discussion for another issue.

Thanks for all your work!

[spheenik]

Hey, it might be a bug, but it smells like corrupt replay data, especially because the tick example crashes as well. Can you provide your replay file in a dropbox or sent to github@martin.schrodt.org? Can you post the exception you get from the tick example?

[keenua]

Thanks for a fast reply, @spheenik !

I've uploaded the replay here.

The last tick it prints info about is 7284:

15:57:05.373 [main] INFO java.lang.Package - tick 7284, synthetic true, had 0 messages

And then the exception is thrown:

---START---

Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at skadistats.clarity.event.Event.raise(Event.java:25) at skadistats.clarity.processor.runner.AbstractFileRunner.initAndRunWith(AbstractFileRunner.java:23) at skadistats.clarity.processor.runner.SimpleRunner.runWith(SimpleRunner.java:36) at skadistats.clarity.Main.run(Main.java:45) at skadistats.clarity.Main.main(Main.java:62) Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at skadistats.clarity.event.Event.raise(Event.java:25) at skadistats.clarity.processor.reader.InputSourceProcessor.processSource(InputSourceProcessor.java:170) at skadistats.clarity.event.AbstractInvocationPoint.invoke(AbstractInvocationPoint.java:72) at skadistats.clarity.event.Event.raise(Event.java:23) ... 4 more Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at skadistats.clarity.wire.Packet.parse(Packet.java:36) at skadistats.clarity.processor.reader.InputSourceProcessor.processEmbedded(InputSourceProcessor.java:246) at skadistats.clarity.event.AbstractInvocationPoint.invoke(AbstractInvocationPoint.java:72) at skadistats.clarity.event.Event.raise(Event.java:23) ... 7 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at skadistats.clarity.wire.Packet.parse(Packet.java:34) ... 10 more Caused by: com.google.protobuf.InvalidProtocolBufferException: Message missing required fields: type at com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(UninitializedMessageException.java:81) at com.google.protobuf.AbstractParser.checkMessageInitialized(AbstractParser.java:71) at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:124) at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:129) at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:49) at skadistats.clarity.wire.common.proto.DotaUserMessages$CDOTAUserMsg_ParticleManager.parseFrom(DotaUserMessages.java:44915) ... 14 more

---END OF EXCEPTION---

[spheenik]

I fixed the bug with the seek example, by reverting a recent commit that did not work correctly. I am still not sure what the problem is with the tick-example, it looks like corrupt data, the real client plays the file without problems though. Still investigating...

[spheenik]

@invokr: Fails to read a CDOTAUserMsg_ParticleManager at tick 7284, but dota client plays back the file without problems. Can you check if you can read it?

[invokr]

"[libprotobuf ERROR google/protobuf/message_lite.cc:123] Can't parse message of type "CDOTAUserMsg_ParticleManager" because it is missing required fields: type"

Which repeats a 1217 times throughout the replay. The rest of it parses fine though. Valve probably screwed up something regarding their protobufs.

[spheenik]

or maybe the field is not required anymore?

[spheenik]

I just tried setting it to optional, and now the replay parses.

The protobuf docs say: "A well-formed message may or may not contain an optional element. When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field."

So, one could say, it makes no sense to define a default for a required element, since you have to supply it anyway. It makes much more sense to define a default for something optional. Which is what Valve corrected, I assume, but it did not show up in GameTracking' dumps yet.

[spheenik]

fixed in clarity-protobuf-4.1