C API Exception

[eaplatanios]

Hi,

The C API method "TF_GraphGetTensorNumDims" throws an exception with message "Node X was not found in the graph" even for valid nodes that are in the graph. This tends to happen with the outputs of particular ops (e.g., reshape and matmul). I think it may have to do with shape inference after looking at the C API implementation but I'm not sure what's wrong. Is there something I need to do to enable shape inference when compiling the shared library? I thought that was enabled by default. Or is there something else that's broken?

Thank you,
Anthony

[asimshankar]

Shape inference should be happening. Please do fill out the full issue template, in particular the library version being used and a code snippet that reproduces the problem.

What you're saying does sound like a bug, but a reproducible example will go a long way :)
(FWIW, the basic unittest passes, so if there is a bug, we'd love to update the unittests to catch that)

Thanks!

[eaplatanios]

@asimshankar I'll try to create a reproducible example using the Java API. Truth be told, I came about this problem while developing the Scala API and don't have a simple code snippet you can use to reproduce this. One thing that might help for your unit tests is that the problem doesn't occur for many ops. A minimal example that causes the problem for me (using Scala syntax but trivial to translate) is this:

val images = placeholder(TFUInt8, Shape(-1, 28, 28))
val vectorizedImages = reshape(images, Shape(-1, 784))

vectorizedImages is an Output with Java API semantics. If you now try to call vectorizedImages.shape, you will get the exception I am describing, saying that Node Reshape was not found in the graph. I hope this can help you reproduce the problem, but if it doesn't I can look into creating a code sample using the Java API.

As for the version, I tried this with both the master branch version (current one) and the r1.1 branch. I compiled without --config=opt as this currently causes another problem for which I am currently creating another issue. :)

Thanks!

[eaplatanios]

Small update: Compiling the current master branch code with the --config=opt flag does not resolve the issue.

[eaplatanios]

@asimshankar After trying to replicate the problem with a simple example in the Java API I found out the following:

1. The reason the previous example was failing was that I was passing a tensor with shape [2, 1] as the second input to Reshape. This needs to be a one-dimensional tensor. I assume that this made this line in the C API fail silently. Thus the shape refiner never registered the op.
2. I noticed the same happening with other ops. For example, passing a one-dimensional tensor to MatMul results in the same behavior.
3. Shouldn't we have an error thrown in the native library whenever invalid inputs or attributes are provided for the ops being constructed?

Thanks!

[asimshankar]

Ah, thanks for tracing this down @eaplatanios ! Sounds like we forgot to clean this up (the precondition mentioned in the comment in the line you pointed to has been met I believe, so we just have to remove that).

I'll try to get that cleared up.

Thanks!

[eaplatanios]

@asimshankar No worries. I'm actually curious. What is the desired behavior for when somebody creates a "Reshape" op using a 2-D tensor provided for the shape? That's just an example, but in general, shouldn't the native library check the op arguments and throw an exception at graph construction time if something is wrong?

[asimshankar]

@eaplatanios : Yes, the desired behavior would be to have the addition of the "Reshape" operator (which was provided invalid arguments) throw an exception. If we didn't ignore the error, that is what would happen. The reason we ignored the error was a temporary one to ease transition, that's taken care of, so after my fix, the Java call to OperationBuilder.build() will throw an exception.

Hope that makes sense.

[eaplatanios]

@asimshankar That makes total sense! Thanks for the prompt responses! :)