Issue 1:
Passing invalid inputs to ndarray.flat will raise an error, but after the interpreter finishes there's a reference count error (python attempts to deallocate the integer 7):

>>> import numpy as np
>>> np.arange(3).flat[None]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IndexError: unsupported iterator index
>>>
*** Reference count error detected:
an attempt was made to deallocate 7 (l) ***

The issue is there in master.

This is probably related to (or a duplicate of) #7982. The reason why I'm not sure this is a duplicate is because the other issue tries assigning to invalid memory, whereas here we're only attempting a read, and that could fail before breaking anything. Update: Since this is a different part of the code (subscription rather than subscripted assignment) and the input type triggering the error is different, I don't think it's related to that issue after all.

Issue 2:
This is a weird bug that is hard to reproduce because, honestly, we don't know what's causing it. A code I work on at NASA uses f2py in a couple of places. And, say, for me, there is never any problem. But for a growing number of our users, they have an issue where f2py just does not work for them. The symptom seems to be that something in their environment causes the f2py compiler detection (done through distutils, I think) to go a bit nuts. For example, for some users if they have:

echo

in their .cshrc/.tcshrc file, f2py stops working.

Now, in some cases, I can get them working by instead of just pointing to the name of the compiler:

f2py --f77exec=mpiifort --f90exec=mpiifort --fcompiler=intelem

I pass in the full path:

f2py --f77exec=/full/path/to/mpiifort --f90exec=/full/path/to/mpiifort --fcompiler=intelem

But, again, this doesn't always work. For some users it doesn't help, the issue seems to be that even though we've told f2py that we are using Intel/intelem, it finds gfortran in the environment, tells ifort to use the flags for that, and ifort -fopenmp crashes.

Eventually, a user was able to "fix" this by adding a line to exec_command.py after:

numpy/numpy/distutils/exec_command.py

Lines 233 to 240
in
d210300

if os.name == 'posix' and use_shell:

# On POSIX, subprocess always uses /bin/sh, override

sh = os.environ.get('SHELL', '/bin/sh')

if is_sequence(command):

command = [sh, '-c', ' '.join(command)]

else:

command = [sh, '-c', command]

use_shell = False

of command.insert(1, '-f'). By doing this, the shell command does not load the rc file in tcsh/csh.

By default, tcsh -c command will source the resource file, which can lead to issues. (For other shells, -f seems to be pretty neutral in, say, bash and zsh. I haven't tested in fish, but I'm guessing fish is weird enough it doesn't work.) We can't envision scenarios where f2py needs environment variables from sourcing the resource/startup files when this command is run.

Our shop mainly uses tcsh as the interactive shell due to historical and practical reasons, so this is important to us, so much so that we are planning on editing any numpy we get from Anaconda, Intel, wherever.

Reproducing code example:

I was able to reproduce this with and without the echo in the rc file using the fib1.f example here: https://docs.scipy.org/doc/numpy/f2py/getting-started.html but another user couldn't replicate it.

Error message:

I'm attaching three files for this so you can see what's happening. In one case I pass in the full FC path and things work. In the next, I don't use the full path and it fails. In the last, I patch our distutils and don't pass in the full path and things work.

fullfc.log

nofullfc.log

nofullfc.patch.log

I'll also attach two files from a colleague who got hurt with this and he inserted prints into the f2py process:

outY.log

outX.log

This seems to show it's during the exec_command for the compiler version.

Numpy/Python version information:

('1.14.2', '2.7.14 |Anaconda, Inc.| (default, Mar 27 2018, 17:29:31) \n[GCC 7.2.0]')