protobuf.js version: 6.8.3
protobuf.js throws an error when trying to decode any map encoded using google's protobuf for c#
message= Message.decode(buffer);
Error: invalid wire type 6 at offset 896
at n.skipType (reader.js:375)
Usually, when a wild wire type 6 appears, the binary data has been corrupted somehow. Are you sure this is not related to this?
Yeah I'm already using arraybuffer as advised.
It works as long as I'm not using any map.
Whenever I use a map (for example map<string, int32> ints = 4;), I'm getting that kind of errors.
Do you have a (hex) dump of such an erroring buffer? Ideally a minimal one, just showing the issue.
I tested with a few minimal examples. a map<int32,int32> seems to work. However a map<string,string> with an empty value is getting me an error (it's a different error, but I am not sure if the error means anything, it just seems to be doing something wrong before)
[50, 9, 10, 7, 116, 101, 115, 116, 75, 101, 121]
should be read with :
message Test
{
map<string,string> test = 6;
}
I just put key="testKey" with value="" in the map for testing.
I'm getting
RangeError: index out of range: 11 + 10 > 11
at r (reader.js:13)
at n.uint32 (reader.js:94)
at n.bytes (reader.js:300)
at n.string (reader.js:321)
at n.Test$decode [as decode] (eval at i (index.js:50), <anonymous>:35:15)
I guess it might be related to https://github.com/dcodeIO/protobuf.js/pull/845
I'm getting the same result with a map<string,int32> and an empty value (0)
From a first look it seems the encoder is omitting the empty value string in C#, while the decoder expects both key and value to be present. As you said, most likely related to #845
Do you also get an error when all keys and values are non-empty?
No I'm not getting the error when keys and values are non-empty.
@dcodeIO I keep encountering this bug.
A fix is ready to merge - did you get a chance to look at it?
What is the fix ? Do you mean
https://github.com/dcodeIO/protobuf.js/pull/1087
?
On Tue, Jul 17, 2018, 19:01 Anna Kosieradzka notifications@github.com
wrote:
@dcodeIO https://github.com/dcodeIO I keep encountering this bug.
A fix is ready to merge - did you get a chance to look at it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dcodeIO/protobuf.js/issues/960#issuecomment-405654468,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACPN_sHQ1leKD4f0gHYqqfsmP5zxR4Qiks5uHhiAgaJpZM4Q7Ho8
.
I was thinking of #845 , but whichever does the job is fine by me.
Ah yeah ok.
I'm also still interested by a fix for this.
This is a blocker to use protobuf generated by c# backends.
On Wed, Jul 18, 2018, 12:46 Anna Kosieradzka notifications@github.com
wrote:
I was thinking of #845 https://github.com/dcodeIO/protobuf.js/pull/845
, but whichever does the job is fine by me.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dcodeIO/protobuf.js/issues/960#issuecomment-405889921,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACPN_rnAxLxteLP4DzQvWZHhXeeIRi2Eks5uHxIJgaJpZM4Q7Ho8
.
Up! Any plans to have a fix for this? It is two years after it was found and it is still reproducible. Both pull requests seem to be absolutely ignored
check these data, when the value is 0 in the map, that value is skipped.
online decoder explained: https://protogen.marcgravell.com/decode?hex=1A-04-08-08-10-01-1A-02-08-03-1A-04-08-07-10-01-1A-02-08-0B-1A-04-08-0A-10-01-1A-02-08-02
26, // 0001 1010 filed=3, tag=2
4, // len=4
8, // 0000 1000 field=1
8, // 8
16, // 0001 0000 field=2
1, // end 8=1
26, // 0001 1010 filed=3, tag=2
2, // len=2, key = 3, value = 0 <----------value is zero
8, // 0000 1000 field=1
3, // 3 3=0
26, // 0001 1010 filed=3, tag=2-
4, // len=4, key=7, value=1 <---------- value is not zero
8, // field=1 tag=0
7, // 7
16, // field=2
1, // end 7=1
26, // 0001 1010 filed=3, tag=2
2, // len=2
8, // field=1 tag = 0
11, // 11=0
26, // 0001 1010 filed=3, tag=2
4, // len=4
8, // field = 1
10, // 10
16, //field=2
1, // 10=1
26, // 0001 1010 filed=3, tag=2
2, // len=2
8, // field=1
2, // 8=2 end
And I check the static js generated. The decoder moves the pointer forward when the value is zero, which makes mistake.
case 2:
reader.skip().pos++;
if (message.strData === $util.emptyObject)
message.strData = {};
key = reader.int32();
reader.pos++; // <- what if value is zero?????????????
message.strData[key] = reader.string();
break;
case 3:
reader.skip().pos++;
if (message.intData === $util.emptyObject)
message.intData = {};
key = reader.int32();
reader.pos++;
message.intData[key] = reader.int32();
break;
All - what is happening with this? I am affected by the issue too. It doesn't appear that a fix for it has been committed - can anyone clarify?
I can confirm that #1087 fixes this issue, and I would be very happy about a merge.
@dcodeIO @alexander-fenster any plans to merge the fix for this issue?
+1 for this - it is quite a serious bug and I would be delighted to see it fixed. I can confirm that #1348 does indeed fix this.
@dcodeIO / @nicolasnoble?
IMHO it's about time to merge the fix
@bcoe / @dcodeIO / @alexander-fenster - would you kindly consider this? I would be absolutely delighted beyond belief to see this merged. Thank you so much!
Most helpful comment
IMHO it's about time to merge the fix