zeromq / pyre

Python port of Zyre
GNU Lesser General Public License v3.0
120 stars 52 forks source link

NULL pointer acess on Windows 7 #137

Open crziter opened 5 years ago

crziter commented 5 years ago

I just tried pyre on Windows 7 and got an exception right here: https://github.com/zeromq/pyre/blob/master/pyre/zhelper.py#L527

Full stack traceback:

Traceback (most recent call last):
  File "C:\Python\Python37-32\lib\threading.py", line 885, in _bootstrap
    self._bootstrap_inner()
  File "C:\Python\Python37-32\lib\threading.py", line 917, in _bootstrap_inner
    self.run()
  File "c:\development\mon\venv\lib\site-packages\fbs_runtime\excepthook\__init__.py", line 84, in run_with_except_hook
    run_original(*args2, **kwargs2)
  File "C:\Python\Python37-32\lib\threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "c:\development\mon\venv\lib\site-packages\pyre\zactor.py", line 59, in run
    self.shim_handler(*self.shim_args, **self.shim_kwargs)
  File "c:\development\mon\venv\lib\site-packages\pyre\zbeacon.py", line 64, in __init__
    self.run()
  File "c:\development\mon\venv\lib\site-packages\pyre\zbeacon.py", line 287, in run
    self.handle_pipe()
  File "c:\development\mon\venv\lib\site-packages\pyre\zbeacon.py", line 216, in handle_pipe
    self.configure(port)
  File "c:\development\mon\venv\lib\site-packages\pyre\zbeacon.py", line 199, in configure
    self.prepare_udp()
  File "c:\development\mon\venv\lib\site-packages\pyre\zbeacon.py", line 71, in prepare_udp
    self._prepare_socket()
  File "c:\development\mon\venv\lib\site-packages\pyre\zbeacon.py", line 135, in _prepare_socket
    netinf = zhelper.get_ifaddrs()
  File "c:\development\mon\venv\lib\site-packages\pyre\zhelper.py", line 113, in get_ifaddrs
    return get_win_ifaddrs()
  File "c:\development\mon\venv\lib\site-packages\pyre\zhelper.py", line 527, in get_win_ifaddrs
    fu = i.first_unicast_address.contents
ValueError: NULL pointer access

A workaround is to add try...except around the block inside for loop, and continue on exception but maybe it's not a solution for the bug.

sphaero commented 5 years ago

either there's no permission or something has changed in C api. Windows 7 is quite old as well. Are you experiencing this on other versions of windows?

crziter commented 5 years ago

I haven't tried on other versions of Windows yet, but I will try it on this weekend.

crziter commented 5 years ago

I just tested on Windows 10 64bit, this issue didn't happen.

playaspec commented 3 years ago

Experiencing this issue on Windows 10 64bit. Machine is the same system as referenced in mentioned pupil-labs issue #2098. FWIW, I'm not a Windows guy, so I'm at a bit of a loss to diagnose the problem further, but here are my observations.

I Dug into the code of zhelper.py and it appears that the issue may involve Windows networking stack API changes or the expected dependencies of the underlying system not being met, and those failures not being tested for or reported.

Line 79 of zhelper.py on Windows appears to be looking for python 2.x, and makes no provisions for 3.x. As a result, win_inet_pton is never imported on our system. I am unsure if this is of any consequence.

get_win_ifaddrs() local inline instance of GetAdaptersAddresses() appears to call Windows version of GetAdaptersAddresses(), using an internal object named GetAdaptersAddresses. This would be MUCH easier to untangle if each object were named in a way to better indicate the intent of each object. From a namespace perspective, this is highly confusing.

The Linux/OSX version of get_ifaddrs() seems to address differences in the way Python2/3 return interface names (string vs array of bytes). Given that the Windows version of this call ignores Python 3 entirely, might this be the reason get_win_ifaddrs() errors with a NULL pointer access? Under Python 3 IP_ADAPTER_ADDRESS.first_unicast_address seems to be unpopulated.

FWIW we managed to find a workaround by removing Cisco AnyConnect Secure Mobility Client Virtual Miniport Adaptor for Windows x64 which appears to no longer trigger this bug.