Java mission messages throw exception

Question

Java mission messages throw exception

markdjacobsen opened this issue 7 years ago · comments

Several of the mission messages generated in Java throw IndexOutOfBoundsException when unpacked. So far I have seen this behavior with msg_mission_count, msg_mission_item, and msg_mission_ack.

For example, msg_mission_count.unpack():

public void unpack(MAVLinkPayload payload) {
payload.resetIndex();

this.count = payload.getUnsignedShort();

this.target_system = payload.getUnsignedByte();

this.target_component = payload.getUnsignedByte();

this.mission_type = payload.getUnsignedByte();
}

The final line throws the following exception (as recorded in Android adb):

11-22 16:32:23.321 10755-10882/io.diux.rogue.rosettadrone D/Rosetta: exception
java.lang.IndexOutOfBoundsException: index=4 out of bounds (limit=4)
at java.nio.Buffer.checkIndex(Buffer.java:528)
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:118)
at com.MAVLink.Messages.MAVLinkPayload.getUnsignedByte(MAVLinkPayload.java:62)
at com.MAVLink.common.msg_mission_count.unpack(msg_mission_count.java:81)
at com.MAVLink.common.msg_mission_count.<init>(msg_mission_count.java:100)
at com.MAVLink.MAVLinkPacket.unpack(MAVLinkPacket.java:420)

Amilcar Lucas · Answer 1 · Tue Feb 20 2018 20:40:30 GMT+0800 (China Standard Time)

@hamishwillee This is a pymavlink issue that should be reported upstream to https://github.com/ardupilot/pymavlink/issues and closed here.

Hamish Willee · Answer 2 · Wed Feb 21 2018 05:57:37 GMT+0800 (China Standard Time)

@jacobsenmd Can you please report upstream as per #806 (comment) ?

Mark Jacobsen · Answer 3 · Wed Mar 14 2018 09:03:48 GMT+0800 (China Standard Time)

Moved to ArduPilot/pymavlink#161

WickedShell · Answer 4 · Wed Mar 14 2018 11:59:59 GMT+0800 (China Standard Time)

This isn't actually an upstream issue. This looks to be associated with the incomplete MAVLink2 changes which were brought in on this fork.

Lorenz Meier · Answer 5 · Wed Mar 14 2018 14:52:02 GMT+0800 (China Standard Time)

@WickedShell It would be very kind if you could you send a PR to address that and keep things in sync.

WickedShell · Answer 6 · Thu Mar 15 2018 03:48:00 GMT+0800 (China Standard Time)

@LorenzMeier It's not my job to correct a bad patch set that was brought in on a downstream fork which I'm not associated with, and was merged without a thorough review.

Please reopen the issue and remove the upstream label as it is still a relevant issue here.

Tom Pittenger · Answer 7 · Thu Mar 15 2018 04:22:55 GMT+0800 (China Standard Time)

Just to be clear, is the problem fixed in upstream?

WickedShell · Answer 8 · Thu Mar 15 2018 04:27:04 GMT+0800 (China Standard Time)

The problem does not exist in upstream. Upstream doesn't support MAVLink2 yet, as the patches either need to be tested, or the PR's for it had flaws the authors would not address.

Mark Jacobsen · Answer 9 · Thu Mar 15 2018 05:03:05 GMT+0800 (China Standard Time)

I have spoken several times with both communities about the immense frustration caused by forking Mavlink's implementation. This will only continue to get worse. Please consider this another data point, and a plea to the leadership of both sides to find a long-term solution. It doesn't do any good to pretend that the communities are independent, when code is entangled at such a low level. I work with a number of different projects that need to support various flavors of mavlink, and having two divergent implementations with the same names and package identifiers is wreaking havoc.

Hamish Willee · Answer 10 · Thu Mar 15 2018 07:49:11 GMT+0800 (China Standard Time)

Reopening for reasons given in #806 (comment)

stale · Answer 11 · Thu Apr 23 2020 13:15:16 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Hamish Willee · Answer 12 · Thu Apr 23 2020 13:47:09 GMT+0800 (China Standard Time)

The fork no longer exists. Closing.