Invalid wire type and index out of range errors #602

smashnick · 2017-01-01T15:06:02Z

protobuf.js version: 6.3.1

I am a novice, so bear with me on the below explanation. Please do not mind the excessive buffer declarations.

I am reading a TCP stream with cap from npm to obtain a TCP payload by listening to a particular port. This is the structure of the packet:

struct PegasusPacket {
uint32_t type;
uint32_t size;
uint8_t *message;
};
The first 4 bytes are the message type
The next 4 bytes are the message size
The remaining size bytes are the protocol buffer encoded message

The packets themselves don't seem to have any issue because I can always extract the type and size faithfully, but when I try to decode the message from my .proto file, things start to go wrong. I have included some buffer examples and stack trace results below. The buffers are the expected message after being reversed.

I also had an issue with index out of range, but I was unable to generate that error for this issue. I think it resolved when I reverse()'d the message buffer..

function getPayloadData(data){
	protobuf.load("../proto/PegasusGame.proto",function(err, root){
		var type,size,message,pl,pl2,pl3,pl4;
		try{
			//slice does some bad things to original data
			pl1 = Buffer.from(data);
			pl2 = Buffer.from(data);
			pl3 = Buffer.from(data);
			pl4 = Buffer.from(data);
			
			//extract 4-byt4 type, 4-byte size, and message
			type = pl1.slice(0,4).reverse().readUIntBE(0,4);
			size = pl2.slice(4,8).reverse().readUIntBE(0,4);
			message = pl3.slice(8,pl4.length).reverse();
			console.log(message);
		} catch(e){
			// console.log(e);
		}
		if(err) throw err;
		if(type !== 19) return;
		
		var PowerHistory = root.lookup("PegasusGame.PowerHistory");
		var PHData = PowerHistory.decode(message);
		console.log(PHData.list);
	});
}

<Buffer 10 01 08 07 22 09 0a 00 20 03 18 02 10 05 08 08 32 0a 0a 0a 18 13 10 01 08 06 22 08 0a 00 3a 02 0a 0a 18 01 c6 10 01 08 07 22 09 0a 00 18 03 d3 10 03 ... >

C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\reader.js:490
            throw Error("invalid wire type: " + wireType);
            ^

Error: invalid wire type: 6
    at Error (native)
    at BufferReader.ReaderPrototype.skipType (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src
\reader.js:490:19)
    at Type._PegasusGame_PowerHistory$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\MessageDecode\no
de_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:14:7)
    at Type.decode_setup [as decode] (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\type.js
:407:25)
    at C:\Users\Nick\Documents\Coding Memes\MessageDecode\test\test_cap.js:102:29
    at finish (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:97:9)
    at process (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:126:13)
    at C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:181:17
    at fetchReadFileCallback (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\@protobufjs\fetch\index.js:32:
19)
    at tryToString (fs.js:455:3)

<Buffer 10 03 08 07 22 09 0a 01 18 02 8a 10 03 08 07 22 09 0a 04 18 31 10 33 08 06 22 08 0a 00 3a 02 0a 0c 18 2c 10 40 08 06 22 08 0a 33 18 12 10 40 08 06 22 ... >

Error: invalid wire type: 4
    at Error (native)
    at BufferReader.ReaderPrototype.skipType (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\reader.js:490:19)
    at Type._PegasusGame_PowerHistoryData$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:34:7)
    at Type._PegasusGame_PowerHistory$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:11:29)
    at Type.decode_setup [as decode] (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\type.js:407:25)
    at C:\Users\Nick\Documents\Coding Memes\MessageDecode\test\test_cap.js:102:30
    at finish (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:97:9)
    at process (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:126:13)
    at C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:181:17
    at fetchReadFileCallback (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\@protobufjs\fetch\index.js:32:19)

<Buffer 10 01 08 07 22 09 0a 00 20 03 18 02 10 05 08 08 32 0a 0a 0a 18 13 10 01 08 06 22 08 0a 00 3a 02 0a 00 18 24 10 40 08 06 22 08 0a 00 18 26 10 49 08 06 ... >

Error: invalid wire type: 7
    at Error (native)
    at BufferReader.ReaderPrototype.skipType (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\reader.js:490:19)
    at Type._PegasusGame_PowerHistory$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:14:7)
    at Type.decode_setup [as decode] (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\type.js:407:25)
    at C:\Users\Nick\Documents\Coding Memes\MessageDecode\test\test_cap.js:102:30
    at finish (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:97:9)
    at process (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:126:13)
    at C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\protobufjs\src\root.js:181:17
    at fetchReadFileCallback (C:\Users\Nick\Documents\Coding Memes\MessageDecode\node_modules\@protobufjs\fetch\index.js:32:19)
    at tryToString (fs.js:455:3)

The text was updated successfully, but these errors were encountered:

dcodeIO · 2017-01-02T04:01:41Z

Well, hard to tell. I assume that the buffer becomes corrupted because it is reversed or something like that, in particular:

//slice does some bad things to original data
// ^ I think it's "reverse" because it moves around your data in place

type = pl1.slice(0,4).reverse().readUIntBE(0,4); // 0,4 doesn't seem like anything readUintBE accepts to me
size = pl2.slice(4,8).reverse().readUIntBE(0,4);
message = pl3.slice(8,pl4.length).reverse(); // why do you reverse the protobuf blob?

could probably just be

type = pl1.readUIntLE(0);
size= pl1.readUIntLE(4);
message = pl1.slice(8/*, 8 + size*/); // or whatever size marks

If I understand your code correctly, then you are reading fixed32 LEs prior to the message anyway , which you could also do like that:

function getPayloadData(data){
	protobuf.load("../proto/PegasusGame.proto",function(err, root){
		var PowerHistory = root.lookup("PegasusGame.PowerHistory");
		var reader = protobuf.Reader.create(data);
		var type = reader.fixed32() >>> 0;
		var size = reader.fixed32() >>> 0;
		if (type === 19) {
			var myPowerHistory = PowerHistory.decode(reader/*, size */); // if size is the length of the protobuf message
			console.log(myPowerHistory.list);
		}
	});
}

You should of course cache the root instance somehow instead of loading it up every time the function is called.

smashnick · 2017-01-02T17:32:33Z

I appreciate you taking the time to answer this. I have modified my code based on what you did and it seems to not throw the wire error now, and it seems to be at least decoding the message against the .proto file now. I shall verify the output after I get done with some post new year's stuff.

I'll explain what I did with type/size/message in my code. Here is an example buffer from a TCP payload that I want:

The first 4 bytes are 0x13000000 which in decimal is 318767104 , if I reverse it, then it becomes 0x13 = 19dec. However, you didn't do any reversal at all and the reader seemed to pick up the 19 just fine.

I assumed everything came in backwards so that is why I reversed everything. Also the reason that I made so many buffers after slicing was because of this:
https://nodejs.org/api/buffer.html#buffer_buf_slice_start_end

"Note that modifying the new Buffer slice will modify the memory in the original Buffer because the allocated memory of the two objects overlap."

Perhaps I have a fundamental misunderstanding in how javascript buffers work? I don't understand how reverse would corrupt anything. Are there any good resources for understanding this better?

Edit:

I have validated outputs and it seems to be decoding the messages correctly, but occasionally, when I receive very specific packets, it will still throw invalid wire type like below.

<Buffer 13 00 00 00 03 01 00 00 0a 13 32 11 08 01 10 ff ff ff ff ff ff ff ff ff 01 18 18 20 42 0a 09 22 07 08 02 10 a1 03 18 03 0a 08 22 06 08 01 10 27 18 18 ... >
Error: invalid wire type: 7
    at Error (native)
    at BufferReader.ReaderPrototype.skipType (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\reader.js:490:19)
    at Type._PegasusGame_PowerHistoryData$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:34:7)
    at Type._PegasusGame_PowerHistory$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:11:29)
    at Type.decode_setup [as decode] (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\type.js:407:25)
    at C:\Users\Nick\Documents\Coding Memes\hearthbot\test\test_cap.js:124:39
    at finish (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:97:9)
    at process (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:126:13)
    at C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:181:17
    at fetchReadFileCallback (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\fetch\index.js:32:19)

It only happens on a certain type of action that I expect to read from the packet.

dcodeIO · 2017-01-02T20:04:34Z

Are there any good resources for understanding this better?

Sure!

Regarding reversed bytes: Little endian byte order (LE) encodes the least significant byte first while big endian (BE) encodes the most significant byte first, but this is only relevant for fixed sized integers and IEEE754 floats, NOT for entire protobuf messages. (see: Endianness)

Regarding buffers: When sliced, buffers create a shallow copy with shared memory. Hence, if you modify the data of one buffer, you also modify the data of the other if the data is in a region visible to both slices. This is most likely not the cause of the invalid wire type-issue, though.

To understand what's wrong with the buffer, you'd need to reverse engineer the wire format. Stripping out the first 8 bytes, this is what we have: 0a 13 32 11 08 01 10 ff ff ff ff ff ff ff ff ff 01 18 18 20 42 0a 09 22 07 08 02 10 a1 03 18 03 0a 08 22 06 08 01 10 27 18 18 ...

There are a couple of examples on how this can be done starting here: #55

jimm1419 · 2017-01-03T00:13:05Z

We're having the same issue. We updated from 5.0.1 which was decoding fine, to version 6.3.1 which has the behavior described here, certain protobuf messages cannot be decoded and throw wire type errors

dcodeIO · 2017-01-03T03:01:24Z

I've created an example for your issue:
https://github.com/dcodeIO/protobuf.js/wiki/How-to-reverse-engineer-a-buffer-by-hand

Hope it helps!

smashnick · 2017-01-03T04:08:33Z

That you for being so thorough.

So then there are no wire types 6 or 7? If we find the point in the buffer where the error occurs, what should be done or can anything be done at all? Where are the points that a buffer can be corrupted, if that is the problem?

I'll print a buffer tonight and go over it tomorrow morning on my commute.

dcodeIO · 2017-01-03T13:27:22Z

If we find the point in the buffer where the error occurs, what should be done or can anything be done at all?

Well, we'll know one of two things: Either the buffer is corrupt or there is a bug with protobuf.js. In both cases there is something we can do about it.

Where are the points that a buffer can be corrupted, if that is the problem?

The usual suspect here is string conversion (see).

smashnick · 2017-01-04T02:21:21Z

So I have taken the time to pan through a couple of buffers to look for any wire types that matched the error given or otherwise. Here are the long results

----------------


Error: invalid wire type: 4
    at Error (native)
    at BufferReader.ReaderPrototype.skipType (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\reader.js:490:19)
    at Type._PegasusGame_PowerHistoryMetaData$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:20:7)
    at Type.decode_setup [as decode] (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\type.js:407:25)
    at Type._PegasusGame_PowerHistoryData$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:31:28)
    at Type._PegasusGame_PowerHistory$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:11:29)
    at Type.decode_setup [as decode] (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\type.js:407:25)
    at C:\Users\Nick\Documents\Coding Memes\hearthbot\test\test_cap.js:97:39
    at finish (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:97:9)
    at process (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:126:13)

BUFFER START


[13 00 00 00 | 11 02 00 00] || [(0a | 0a) 32 08 08 07 10 00 18 38 20 04] [(0a | 08) 22 06 08 03 10 19 18 01] [(0a | 09) 22 07 08 03 10 a2 03 18 02] [(0a | 09) 22 07 08 03 10 8d 02 18 01] [(0a | 09) 22 07 08 03 10 ae 03 18 01] [(0a | 09) 22 07 08 2c 10 87 02 18 03] [(0a 09) 22 07 08 22 10 87 02 18 02] [(0a | b7) 01 12 b4 01 08 38 12 07 43 53
31 5f 31 33 30 1a 04 08 0c 10 00 1a 04 08 2c 10 00 1a 04 08 30 10 01 1a 04 08 31 10 01 1a 04 08 32 10 02 1a 04 08 35 10 38 1a 05 08 bc 01 10 00 1a 05 08 bd 01 10 00 1a 05 08 be 01 10 00 1a 05 08 bf 01 10 00 1a 05 08 c2 01 10 00 1a 05 08 c5 01 10 00 1a 05 08 c9 01 10 03 1a 05 08 ca 01 10 05 
1a 05 08 cb 01 10 02 1a 05 08 84 02 10 00 1a 05 08 87 02 10 02 1a 05 08 a9 02 10 00 1a 05 08 e0 02 10 00 1a 05 08 e8 02 10 00 1a 05 08 f4 02 10 00 1a 05 08 f8 02 10 00 1a 05 08 bc 03 10 00 1a 05 08 d2 03 10 01 1a 05 08 df 03 10 00] [(0a | 09) 22 07 08 38 10 87 02 18 00] [(0a | 09) 22 07 08 38 10 85 02 
18 01] [(0a | 09) 22 07 08 03 10 8d 03 18 38] [(0a | 09) 22 07 08 38 10 8b 02 18 04] [(0a | 13) 32 11 08 03 10 ff ff ff ff ff ff ff ff ff 01 18 38 20 04] [(0a | 05) 42 03 12 01 04] [(0a | 09) 22 07 08 04 10 be 02 18 02] [(0a | 09) 22 07 08 04 10 be 02 18 00] [(0a | 09) 42 07 12 01 04 18 01 20 02] [(0a | 08) 22 06 08 04 10 12 18 38] [(0a | 08) 22 06 08 04 10 2c 18 03] [(0a | 02) 3a 00] [(0a | 08) 22 06 08 38 10 31 18 04] [(0a | 0a) 32 08 08 06 10 00 18 01 20 00] [(0a | 09) 22 07 08 02 10 f0 02 18 01] [(0a | 09) 22 07 08 01 10 f1 02 18 02] [(0a | 08) 22 06 08 04 10 2b 18 00] [(0a | 08) 22 06 08 04 10 31 18 04] [(0a | 09) 22 07 08 02 10 8e 03 18 01] [(0a | 09) 22 07 08 02 10 9c 03 18 01] [(0a | 09) 22 07 08 04 10 87 02 18 00] [(0a | 08) 22 06 08 04 10 2c 18 00] [(0a | 02) 3a 00] [(0a | 09) 22 07 08 03 10 8a 02 18 01] [(0a | 09) 22 07 08 03 10 e6 02 18 02] [(0a | 02) 3a 00]



BUFFER END

-----------------

-----------------

Error: invalid wire type: 7
    at Error (native)
    at BufferReader.ReaderPrototype.skipType (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\reader.js:490:19)
    at Type._PegasusGame_PowerHistoryData$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:34:7)
    at Type._PegasusGame_PowerHistory$decode [as decode] (eval at eof (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\codegen\index.js:102:25), <anonymous>:11:29)
    at Type.decode_setup [as decode] (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\type.js:407:25)
    at C:\Users\Nick\Documents\Coding Memes\hearthbot\test\test_cap.js:97:39
    at finish (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:97:9)
    at process (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:126:13)
    at C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\protobufjs\src\root.js:181:17
    at fetchReadFileCallback (C:\Users\Nick\Documents\Coding Memes\hearthbot\node_modules\@protobufjs\fetch\index.js:32:19)
BUFFER START


[13 00 00 00 | 03 01 00 00] || [(0a | 13) 32 11 08 01 10 ff ff ff ff ff ff ff ff ff 01 18 21 20 42] [(0a | 09) 22 07 08 02 10 a1 03 18 01] [(0a | 08) 22 06 08 01 10 27 18 21] [(0a | 08) 22 06 08 01 10 25 18 42] [(0a | 08) 22 06 08 21 10 26 18 01] [(0a | 09) 22 07 08 01 10 c6 01 18 0a] [(0a | 08) 22 06 08 01 10 13 18 0b] [(0a | 09) 22 07 08 02 10 e6 02 18 02] [(0a | 08) 22 06 08 42 10 24 18 01] [(0a | 09) 22 07 08 42 10 be 02 18 03] [(0a | 09) 22 07 08 42 10 be 02 18 00] [(0a | 09) 42 07 12 01 42 18 01 20 03] [(0a | 08) 22 06 08 42 10 12 18 21] [(0a | 08) 22 06 08 42 10 2c 18 04] [(0a | 09) 22 07 08 21 10 a9 02 18 01] [(0a | 08) 22 06 08 21 10 2b 18 01] [(0a | 08) 22 06 08 01 10 27 18 00] [(0a | 08) 22 06 08 01 10 25 18 00] [(0a | 08) 22 06 08 21 10 26 18 00] [(0a | 08) 22 06 08 42 10 24 18 00] [(0a | 02) 3a 00] [(0a | 08) 22 06 08 01 10 13 18 0a] [(0a | 0a) 32 08 08 05 10 02 18 02 20 00] [(0a | 09) 22 07 08 01 10 c6 01 18 0c] [(0a | 02) 3a 00]


BUFFER END

All messages appeared to be length delimited.
Notice in the first one how there are two bytes [(0a | b7) ... ] that gave a length of 183 bytes for the message. However 184 bytes are given.

var msgCount = "01 12 b4 01 08 38 12 07 43 53 31 5f 31 33 30 1a 04 08 0c 10 00 1a 04 08 2c 10 00 1a 04 08 30 10 01 1a 04 08 31 10 01 1a 04 08 32 10 02 1a 04 08 35 10 38 1a 05 08 bc 01 10 00 1a 05 08 bd 01 10 00 1a 05 08 be 01 10 00 1a 05 08 bf 01 10 00 1a 05 08 c2 01 10 00 1a 05 08 c5 01 10 00 1a 05 08 c9 01 10 03 1a 05 08 ca 01 10 05 1a 05 08 cb 01 10 02 1a 05 08 84 02 10 00 1a 05 08 87 02 10 02 1a 05 08 a9 02 10 00 1a 05 08 e0 02 10 00 1a 05 08 e8 02 10 00 1a 05 08 f4 02 10 00 1a 05 08 f8 02 10 00 1a 05 08 bc 03 10 00 1a 05 08 d2 03 10 01 1a 05 08 df 03 10 00".split(" ").length"

//console.log(msgCount) --> 184

So perhaps it is the data that is wrong. However, if I continue reverse engineering the buffer, I run into wire type 7 before wire type 4, which is what protobuf.js decided the error was.

For the second one, I did not find an error in the data when verifying the encoding, so I have no idea why an invalid wire type is thrown.

What do you think?

dcodeIO · 2017-01-04T12:10:19Z

I'd rather guess 0a is a tag (id 1, wireType 2). Notice that the msb is not set (00001010₂), hence it cannot be the first byte of a two bytes long varint.

smashnick · 2017-01-04T14:52:10Z

I agree that 0a is not a varint and the tag is 1 and wire type is 2, and b7 01 is the varint length because wire-type 2 is length delimited. b7 01 is 183, and 183 bytes follow, which was a mistake on my part in the previous post.

I'll come back again after I looked at the individual messages.

smashnick · 2017-01-05T14:50:04Z

0a 09 42 07 12 01 04 18 01 20 02

This buffer segment seemed to be the culprit for throwing wire type = 4, from looking at it. I don't know what to do with this information other than create my own protobufjs, which is probably impractical. I would just throw out the message and ignore it if it threw a wire type because the rest of the buffer looked fine.

dcodeIO · 2017-01-05T14:56:18Z

0a	id 1, wireType 2
09	length 9

42 07 12 01 04 18 01 20 02

42	id 8, wireType 2
07	length 7

12 01 04 18 01 20 02

12	id 2, wireType 2
01	length 1
04	?? <-- what's the definition of this field (id 2 in a message with two varints like below)?
18	id 3, wireType 0 (varint)
01	value 1
20	id 4, wireType 0 (varint)
02	value 2

smashnick · 2017-01-05T16:05:38Z

message PowerHistoryMetaData {
	enum MetaType {
		META_TARGET = 0;
		META_DAMAGE = 1;
		META_HEALING = 2;
	}
	
	repeated int32 info = 2; <---- Here is the field you are looking for.
	optional .PegasusGame.PowerHistoryMetaData.MetaType meta_type = 3;
	optional int32 data = 4;
}

It says int32, but the data is encoded otherwise.

dcodeIO · 2017-01-05T16:08:31Z

What happens when you change that to

repeated int32 info = 2 [packed=true];

…602

dcodeIO · 2017-01-06T00:23:09Z

With this commit, protobuf.js does not rely on reflection information anymore to decide whether to generate a decoder for packed or non-packed repeated fields. It now just checks the wire format and acts accordingly. While I am not 100% sure that this caused your issue, it is likely. Give 6.4.3 a try and let me know!

smashnick · 2017-01-06T00:39:03Z

That fixed everything. Not seeing a single error anymore! :D Thank you for working through this with me and producing this awesome module!

dcodeIO added a commit that referenced this issue Jan 2, 2017

New: Be more verbose when throwing invalid wire type errors, see #602

28ce07d

dcodeIO added the unsure label Jan 2, 2017

dcodeIO added question and removed unsure labels Jan 3, 2017

dcodeIO added a commit that referenced this issue Jan 5, 2017

Fixed: Always decode packed/non-packed based on wire format only, see #…

11fb1a6

…602

dcodeIO closed this as completed Jan 6, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Invalid wire type and index out of range errors #602

Invalid wire type and index out of range errors #602

smashnick commented Jan 1, 2017 •

edited

Loading

dcodeIO commented Jan 2, 2017 •

edited

Loading

smashnick commented Jan 2, 2017 •

edited

Loading

dcodeIO commented Jan 2, 2017 •

edited

Loading

jimm1419 commented Jan 3, 2017

dcodeIO commented Jan 3, 2017 •

edited

Loading

smashnick commented Jan 3, 2017

dcodeIO commented Jan 3, 2017

smashnick commented Jan 4, 2017 •

edited

Loading

dcodeIO commented Jan 4, 2017 •

edited

Loading

smashnick commented Jan 4, 2017

smashnick commented Jan 5, 2017 •

edited

Loading

dcodeIO commented Jan 5, 2017 •

edited

Loading

smashnick commented Jan 5, 2017

dcodeIO commented Jan 5, 2017

dcodeIO commented Jan 6, 2017

smashnick commented Jan 6, 2017

Invalid wire type and index out of range errors #602

Invalid wire type and index out of range errors #602

Comments

smashnick commented Jan 1, 2017 • edited Loading

dcodeIO commented Jan 2, 2017 • edited Loading

smashnick commented Jan 2, 2017 • edited Loading

dcodeIO commented Jan 2, 2017 • edited Loading

jimm1419 commented Jan 3, 2017

dcodeIO commented Jan 3, 2017 • edited Loading

smashnick commented Jan 3, 2017

dcodeIO commented Jan 3, 2017

smashnick commented Jan 4, 2017 • edited Loading

dcodeIO commented Jan 4, 2017 • edited Loading

smashnick commented Jan 4, 2017

smashnick commented Jan 5, 2017 • edited Loading

dcodeIO commented Jan 5, 2017 • edited Loading

smashnick commented Jan 5, 2017

dcodeIO commented Jan 5, 2017

dcodeIO commented Jan 6, 2017

smashnick commented Jan 6, 2017

smashnick commented Jan 1, 2017 •

edited

Loading

dcodeIO commented Jan 2, 2017 •

edited

Loading

smashnick commented Jan 2, 2017 •

edited

Loading

dcodeIO commented Jan 2, 2017 •

edited

Loading

dcodeIO commented Jan 3, 2017 •

edited

Loading

smashnick commented Jan 4, 2017 •

edited

Loading

dcodeIO commented Jan 4, 2017 •

edited

Loading

smashnick commented Jan 5, 2017 •

edited

Loading

dcodeIO commented Jan 5, 2017 •

edited

Loading