Bug #927
Logger randomly crashes
| Status: | Resolved | Start date: | 03/05/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | J. Moringen | % Done: | 100% | |
| Category: | Common Lisp Tools | |||
| Target version: | - |
Description
After some time of correct results the logger crashes:
The encoded data
0A B9 01 32 0E 2F 6E 61 6F 2F 68 65 61 64 70 6F 73 65 2F 3A 17 2E 72 73 74 2E 76 69 73 69 6F 6E 2E 48 65 61 64 4F 62 6A 65 63 74 73 4A 5E 0A 2C 0A 02 08 04 12
0C 0A 06 08 AA 01 10 A1 02 10 3E 18 3E 22 0F 0D 9D 1A 2F C2 15 3D 79 95 C1 1D 00 00 00 00 42 07 50 61 72 74 6E 65 72 0A 2E 0A 02 08 06 12 13 0A 0D 08 FF FF FF
FF FF FF FF FF FF 01 10 55 10 30 18 2F 22 0F 0D C6 1C 21 BF 15 B2 80 38 C2 1D 00 00 00 00 42 02 55 4E 7A 16 10 A5 AD EF A2 B5 D0 AE 02 18 C8 E6 A0 EE A7 D0 AE
02 20 00 28 00 E2 06 15 0A 10 15 33 0E 50 A0 31 45 13 82 FC 03 91 BA A7 1B 4A 10 A1 05 10 01 18 00
could not be decoded :
After unpacking, the notification
#<RSB.PROTOCOL:FRAGMENTED-NOTIFICATION {1007DF1663}>
[standard-object]
Slots with :INSTANCE allocation:
NOTIFICATION = #<RSB.PROTOCOL:NOTIFICATION {1007DF16B3}>
NUM-DATA-PARTS = 1
DATA-PART = 0
could not be converted into an event.
Caused by:
> The wire data
> #(10 44 10 2 8 4 18 12 10 6 8 170 1 16 161 2 16 62 24 62 34 15 13 157 26 47 194 21 61 121 149 193 29 0 0 0 0 66 7 80 97 114 116 110 101 114 10 46 10 2 8 6 18
> 19 10 13 8 255 255 255 255 255 255 255 255 255 1 16 85 16 48 24 47 34 15 13 198 28 33 191 21 178 128 56 194 29 0 0 0 0 66 2 85 78)
> (in :|.rst.vision.HeadObjects| wire-schema) could not be converted to domain type :UNDETERMINED
> Caused by:
> > The value 18446744073709551615 is not of type (SIGNED-BYTE 32).
This is somehow repeatable.
This is version 0.6 but I cannot assign bugs to it.
Related issues
History
#1 Updated by J. Wienke about 12 years ago
Btw. running on 64 bit.
#2 Updated by J. Moringen about 12 years ago
Short answer¶
This is caused by a bug in the protocol buffer compiler for which I will commit a fix now.
Long answer¶
The data looks like this
RST.VISION:HEAD-OBJECTS
0: 0A 2C .head_objects RST.VISION:HEAD-OBJECT
2: 0A 02 .tracking_info RST.TRACKING:TRACKING-INFO
4: 08 04 (value: 4) .id uint32
6: 12 0C .region RST.GEOMETRY:BOUNDING-BOX
8: 0A 06 .top_left RST.MATH:VEC2DINT
10: 08 AA 01 .x
13: 10 A1 02 .y
16: 10 3E .width
18: 18 3E .height
20: 22 0F .pose RST.MATH:VEC3DFLOAT
22: 0D 9D 1A 2F C2 15 3D 79 95 C1 1D 00 00 00 00 ...
37: 42 07 .vfoa_target bytes
39: 50 61 72 74 6E 65 72 (value: "Partner")
46: 0A 2E .head_objects RST.VISION:HEAD-OBJECT
48: 0A 02 .tracking_info RST.TRACKING:TRACKING-INFO
50: 08 06 .id uint32
52: 12 13 .region RST.GEOMETRY:BOUNDING-BOX
54: 0A 0D .top_left RST.MATH:VEC3DFLOAT
56: 08 FF FF FF FF FF FF FF FF FF 01 (value: -1) .x
67: 10 55 .y
69: 10 30 .width
71: 18 2F .height
73: 22 0F
75: 0D C6 1C 21 BF 15 B2 80 38 C2 1D 00 00 00 00 .pose RST.MATH:VEC3DFLOAT
90: 42 02 .vfoa_target bytes
92: 55 4E (value: "UN")
The bug is triggered by the sequence FF FF FF FF FF FF FF FF FF 01 at offset 56 which is the encoding produced by the Vec2DInt.x field
message Vec2DInt {
--> required int32 x = 1 [default = 0]; <--
required int32 y = 2 [default = 0];
}
for the value -1. int32 uses variable width encoding for 32-bit integers. This type produces produces short sequences for small positive integers (i.e. usually a single byte or two bytes) but exceedingly large sequences for negative values. Alternatives are sint32 and sfixed32 (if negative values are actually sound and not the result of a bug).
#3 Updated by J. Moringen about 12 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset r3421.