Operating System: Linux
Platform: PC

I checked, and I see the same behaviour with Beryllium-SR4 but Lithium-SR4 works ok. So I guess this is something to do with the stricter YANG checking in Beryllium?

The full stack trace would be nice since it's cut off at the interesting part and you cant see the cause of the NPE.

I've deleted most of the log to leave the stuff potentially relevant to the error.

Attachment karaf.log has been added with description: last couple of hundred lines of the log

Hi Giles,

I've looked at the log and this behavior is indeed strange. Can you please also provide yang models, so I can reproduce this?

will mail you a zip of the YANG models (comes to 1.4MB even as a ZIP so can't send it here).

This part has been omitted from original report:

Caused by: java.lang.NullPointerException
at org.opendaylight.yangtools.yang.common.QName.create(QName.java:211)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.TypeUtils.typeEffectiveSchemaPath(TypeUtils.java:209)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.effective.type.UnsignedIntegerTypeEffectiveStatementImpl.<init>(UnsignedIntegerTypeEffectiveStatementImpl.java:33)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.TypeStatementImpl$Definition.createEffective(TypeStatementImpl.java:188)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.TypeStatementImpl$Definition.createEffective(TypeStatementImpl.java:82)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementContextBase.buildEffective(StatementContextBase.java:445

NPE is caused by QName.create() being called with a null base, which in turn points to TypeUtils doing:

final SchemaPath path = stmtCtx.getSchemaPath().get();
final QName qname = stmtCtx.getFromNamespace(QNameCacheNamespace.class,
QName.create(path.getParent().getLastComponent()

In this path.getParent() is YangInstanceIdentifier.EMPTY, which is the only case where getLastComponent() returns null.

The stack classes involved are pointing at an uint typedef or leaf. Models need to be analyzed.

boron: https://git.opendaylight.org/gerrit/49143

will report more information so we can track it down.

Thinking about this a bit more, the probable cause for this is a free-standing 'type' statement – which would constitute invalid yang.

(In reply to Giles Heron from comment #5)
> will mail you a zip of the YANG models (comes to 1.4MB even as a ZIP so
> can't send it here).

Hi Giles, send the models to Peter Kajsa or Igor Foltin (Yang team). Thanks.

will do once I have the models. For this one I need access to a real cisco switch that has the issue (7267 doesn't occur with CSR1Kv but only with a real switch). Kevin/Jason have the switches so I need to get hold of them once they're in today.

Furthermore, this is a side-effect of when and how we validate sub-statements – which happens only after the parent has been fully declared.

Hence I can do

container foo {
type uint8;
}

and while it will blow up, it will do so very late in processing, at which point someone may have asked for the effective statement.

That leads to TypeEffectiveStatementImpl being invoked in a context, which the implementation does not expect (hey, 'type' can occur only nested in a different statement, hence it's parent path is non-empty... kaboom).

BUG-7037 tracks an improvement to lookups, which means that the fact that 'type' statement has no place under container the very first time we attempt to start to define it, throwing a SourceException pinpointing the offender – allowing NETCONF to properly exclude it (and hence fix this particular issue).

Workaround patch for parser to add the offender identification – that should be sufficient for NETCONF to prune the offender. The root cause needs to be still investigated.

master: https://git.opendaylight.org/gerrit/49351

boron: https://git.opendaylight.org/gerrit/49433

Hi Giles, I tested the models you provided and the only problem came up with the model ned-switching-devs@2016-04-20.

deviation /ned:native/ned:class-map/ned:match/ned:access-group/ned:index {
deviate replace {
type uint32

}
}

The issue was that the type uint32 statement had an empty parent.
It is a problem in yang parser code, so I will open a new bug for that.

Attachment short.log has been added with description: ODL log (starting with the instance data)

Attachment openconfig-interfaces@2015-11-20.yang has been added with description: YANG model with missing instance data