nd.random.uniform() FP exception when called with bad shape

[michaelkr]

Description

Calling nd.random.uniform() with a improper shape spec causes a hard exception and python exit.

Environment info

mx.version
'1.2.1'

Running from Python 3.6.9 |Anaconda, Inc.| (default, Jul 30 2019, 19:07:31)

Build info (Required if built from source)

Did not build from source - using version that came with Conda.

Error Message:

Floating exception

Minimum reproducible example

nd.random.uniform(-1,1,(2,0))

What have you tried to solve it?

Looked through source code - it looks like the call goes from master/python/mxnet/ndarray/random.py either to some internal C call.

Or, it might go to the master/python/mxnet/ndarray/numpy/random.py code for uniform() - which does not check for this case (lines 123-132).

[mxnet-label-bot]

Hey, this is the MXNet Label Bot.
Thank you for submitting the issue! I will try and suggest some labels so that the appropriate MXNet community members can help resolve it.
Here are my recommended label(s): Bug

[lanking520]

@michaelkr Thanks for reporting this issue. Is that reproducible on MXNet 1.5? Apart from that, could you please provide the shape you tested?

[michaelkr]

@lanking520 I will try to get mxnet 1.5 installed with conda on another machine and test.

The exact calling sequence to duplicate is:

start python, then:

from mxnet import nd
nd.random.uniform(-1,1,(2,0))

which exits python with a "Floating exception" that cannot be caught.

[xidulu]

@michaelkr
What you are trying to create is something called "Zero-size tensor", which, as far as I'm concerned, is not supported by mx.ndarray, as the zero in the shape means unknown rather than a concrete number, see bullet 2 in #14253 for more details.
However, the deep numpy API supports zero-size tensor, I'm not sure if the version installed using pip includes this feature, but if you build the latets version of mxnet from source, you could call the api like this:

>>> from mxnet import np, npx
>>> np.random.uniform(-1,1, (2,0))
array([], shape=(2, 0))

[michaelkr]

Thanks @xidulu ...it was actually a typo in my code, so I don't need the workaround. I submitted it here because I felt it should result in a catchable exception or similar behavior, not a crash.

[xidulu]

@michaelkr
I tried your code and the error handling functionality worked well on my machine:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ubuntu/mxnet_master_develop/python/mxnet/ndarray/random.py", line 110, in uniform
    [low, high], shape, dtype, ctx, out, kwargs)
  File "/home/ubuntu/mxnet_master_develop/python/mxnet/ndarray/random.py", line 48, in _random_helper
    return random(*params, shape=shape, dtype=dtype, ctx=ctx, out=out, **kwargs)
  File "<string>", line 60, in _random_uniform
  File "/home/ubuntu/mxnet_master_develop/python/mxnet/_ctypes/ndarray.py", line 107, in _imperative_invoke
    ctypes.byref(out_stypes)))
  File "/home/ubuntu/mxnet_master_develop/python/mxnet/base.py", line 254, in check_call
    raise MXNetError(py_str(_LIB.MXGetLastError()))
mxnet.base.MXNetError: [14:09:27] ../src/imperative/./imperative_utils.h:146: Operator _random_uniform inferring shapes failed.
input shapes:
output shapes:
[-1,1]
operator attributes:
ctx : cpu(0)
shape : (0, 1)
high : 1
low : 0

Stack trace:
  [bt] (0) /home/ubuntu/mxnet_master_develop/python/mxnet/../../build/libmxnet.so(dmlc::LogMessageFatal::~LogMessageFatal()+0x32) [0x7f1a3b9212f2]
  [bt] (1) /home/ubuntu/mxnet_master_develop/python/mxnet/../../build/libmxnet.so(mxnet::imperative::SetShapeType(mxnet::Context const&, nnvm::NodeAttrs const&, std::vector<mxnet::NDArray*, std::allocator<mxnet::NDArray*> > const&, std::vector<mxnet::NDArray*, std::allocator<mxnet::NDArray*> > const&, mxnet::DispatchMode*)+0x548) [0x7f1a3de41378]
  [bt] (2) /home/ubuntu/mxnet_master_develop/python/mxnet/../../build/libmxnet.so(mxnet::Imperative::Invoke(mxnet::Context const&, nnvm::NodeAttrs const&, std::vector<mxnet::NDArray*, std::allocator<mxnet::NDArray*> > const&, std::vector<mxnet::NDArray*, std::allocator<mxnet::NDArray*> > const&)+0x371) [0x7f1a3de32721]
  [bt] (3) /home/ubuntu/mxnet_master_develop/python/mxnet/../../build/libmxnet.so(MXImperativeInvokeImpl(void*, int, void**, int*, void***, int, char const**, char const**)+0xb1e) [0x7f1a3dd1f08e]
  [bt] (4) /home/ubuntu/mxnet_master_develop/python/mxnet/../../build/libmxnet.so(MXImperativeInvokeEx+0x534) [0x7f1a3dd202c4]
  [bt] (5) /home/ubuntu/anaconda3/lib/python3.7/lib-dynload/../../libffi.so.6(ffi_call_unix64+0x4c) [0x7f1a78649630]
  [bt] (6) /home/ubuntu/anaconda3/lib/python3.7/lib-dynload/../../libffi.so.6(ffi_call+0x22d) [0x7f1a78648fed]
  [bt] (7) /home/ubuntu/anaconda3/lib/python3.7/lib-dynload/_ctypes.cpython-37m-x86_64-linux-gnu.so(_ctypes_callproc+0x2ce) [0x7f1a7865ff7e]
  [bt] (8) /home/ubuntu/anaconda3/lib/python3.7/lib-dynload/_ctypes.cpython-37m-x86_64-linux-gnu.so(+0x139b4) **[0x7f1a786609b4]**

I could not find out a way to reproduce the floating number exception (which should behave like core dump) you mentioned so far.

[michaelkr]

@xidulu Thanks for testing - I see that on my MacOS machine, running mxnet 1.5, I get the same result as you - a catchable exception.

But on my CentOS 7.5 machine, again with mxnet 1.5, it just core dumps.

[xidulu]

@michaelkr
I tested it on my CentOS 7.0 machines and it worked perfectly fine. I would suggest you dump out the core file and use gdb to obtain the back trace for further information:

>>> gdb python core // core file
>>> bt