Error on smile decode

[sgmiller]

Occurs in 2.6.x but not 2.5.5. Here is the stack trace when reading a large generic Map<String,Object>

com.fasterxml.jackson.core.JsonParseException: Invalid type marker byte 0xfa for expected field name (or END_OBJECT marker)
 at [Source: file:/var/lib/tomcat8/webapps/ROOT/WEB-INF/classes/layoutData/layouts.smile; line: -1, column: 3700060]
        at com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1581)
        at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:533)
        at com.fasterxml.jackson.dataformat.smile.SmileParser._handleFieldName(SmileParser.java:1571)
        at com.fasterxml.jackson.dataformat.smile.SmileParser.nextToken(SmileParser.java:587)
        at com.fasterxml.jackson.databind.deser.std.MapDeserializer._readAndBindStringMap(MapDeserializer.java:484)
        at com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:341)
        at com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:26)
        at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3736)
        at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2698)

[sgmiller]

The file is written as part of our build process and uses the same mapper to write and then subsequently read the file at runtime. The mapper is configured as:

public static ObjectMapper layoutMapper;
    static { 
        SmileFactory factory = new SmileFactory();
        factory.configure(SmileGenerator.Feature.CHECK_SHARED_NAMES, true);
        factory.configure(SmileGenerator.Feature.CHECK_SHARED_STRING_VALUES, true);
        layoutMapper = new ObjectMapper(factory, true);
    }

[cowtowncoder]

Could this possibly be due to #30? If it was easy to try out local built from 2.6 branch it should be possible to see; fix was not in 2.6.4, but is checked in 2.6 branch.

Otherwise what I will need is a reproduction to see what is causing this; the problem could be in either writing or reading side, although I suspect it is more likely to be on reading side. And I hope that's where it is, because consequences are worse if generator was to write incorrectly encoded data.

[sgmiller]

It could be. I'll checkout from git and see if the changes in #30 fix it.

[cowtowncoder]

@sgmiller Have you had a chance to look at this? 2.7.0 was finally released few weeks ago, so it should be bit easier to verify this now.

[sgmiller]

I'll give it a look this week, thanks.

[cowtowncoder]

Can not reproduce at this point. May be refiled at https://github.com/FasterXML/jackson-dataformats-binary where Smile format module will be moving.