Version 0.6.0 prints a lot of errors #854

New Issue

2016-05-04T17:43:00+02:00

yurivict commented

2016-05-04 17:43:00 +02:00

(Migrated from github.com)

Many error messages like these are printed during the runtime:

2016-05-04 06:48:38,301 - ERROR - sock.sendall error: [Errno 9] Bad file descriptor
2016-05-04 06:49:07,596 - ERROR - sendDataThread ID: 35046649488 ignoring command advertisepeer because the thread is not in stream1
2016-05-04 06:52:20,375 - ERROR - sendDataThread ID: 34690271696 ignoring command advertisepeer because the thread is not in stream1

Also in the beginning this error message is printed:

Namecoin connection test: Socket error in RPC connection: [Errno 61] Connection refused
Exception in thread singleListener:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/local/share/pybitmessage/class_singleListener.py", line 101, in run
    socketObject, sockaddr = sock.accept()
  File "/usr/local/lib/python2.7/socket.py", line 206, in accept
    sock, addr = self._sock.accept()
error: [Errno 4] Interrupted system call

FreeBSD-10.3

Many error messages like these are printed during the runtime: ``` 2016-05-04 06:48:38,301 - ERROR - sock.sendall error: [Errno 9] Bad file descriptor 2016-05-04 06:49:07,596 - ERROR - sendDataThread ID: 35046649488 ignoring command advertisepeer because the thread is not in stream1 2016-05-04 06:52:20,375 - ERROR - sendDataThread ID: 34690271696 ignoring command advertisepeer because the thread is not in stream1 ``` Also in the beginning this error message is printed: ``` Namecoin connection test: Socket error in RPC connection: [Errno 61] Connection refused Exception in thread singleListener: Traceback (most recent call last): File "/usr/local/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File "/usr/local/share/pybitmessage/class_singleListener.py", line 101, in run socketObject, sockaddr = sock.accept() File "/usr/local/lib/python2.7/socket.py", line 206, in accept sock, addr = self._sock.accept() error: [Errno 4] Interrupted system call ``` FreeBSD-10.3

PeterSurda commented

2016-05-04 20:25:23 +02:00

(Migrated from github.com)

The first three errors are fine, they just mean there are issues with communicating with the remote node.

The middle one (namecoin) is also ok, it probably means you don't have namecoin installed. It's optional.

The last one looks like a bug, or it simply could be some kernel-level security system preventing opening a listening socket (like selinux or apparmor on linux, I don't know FreeBSD).

~~I remember there was a patch for FreeBSD which I didn't have time to merge and test: f3a1af0f32 . Try it and let me know if it helps.~~ I just noticed it's for netbsd so ignore it.

The first three errors are fine, they just mean there are issues with communicating with the remote node. The middle one (namecoin) is also ok, it probably means you don't have namecoin installed. It's optional. The last one looks like a bug, or it simply could be some kernel-level security system preventing opening a listening socket (like selinux or apparmor on linux, I don't know FreeBSD). ~~I remember there was a patch for FreeBSD which I didn't have time to merge and test: https://github.com/Bitmessage/PyBitmessage/commit/f3a1af0f3291ab1e41192a19f647f300aa38c27e . Try it and let me know if it helps.~~ I just noticed it's for netbsd so ignore it.

yurivict commented

2016-05-04 21:59:45 +02:00

(Migrated from github.com)

The last one looks like a bug, or it simply could be some kernel-level security system preventing opening a listening socket (like selinux or apparmor on linux, I don't know FreeBSD).

This isn't selinux or anything like this. The process received some signal and it kicked the system call out of the waiting state. Normally if the process uses signals internally (or in any case) it is a good idea to have all system calls in a cycle that re-runs it in case of EINTR.

> The last one looks like a bug, or it simply could be some kernel-level security system preventing opening a listening socket (like selinux or apparmor on linux, I don't know FreeBSD). This isn't selinux or anything like this. The process received some signal and it kicked the system call out of the waiting state. Normally if the process uses signals internally (or in any case) it is a good idea to have all system calls in a cycle that re-runs it in case of EINTR.

PeterSurda commented

2016-05-04 22:04:24 +02:00

(Migrated from github.com)

This looks like some FreeBSD oddity. I tested this release on 4 linux distros, 2 Windows and 2 OSX versions and I never saw anything like this. What is sending the signal and which signal?

But you're right, an exception in the accept loop shouldn't terminate the thread.

This looks like some FreeBSD oddity. I tested this release on 4 linux distros, 2 Windows and 2 OSX versions and I never saw anything like this. What is sending the signal and which signal? But you're right, an exception in the accept loop shouldn't terminate the thread.

yurivict commented

2016-05-04 22:29:58 +02:00

(Migrated from github.com)

I don't know what signal was. But for example SIGCHLD can cause this if the process starts child processes.

PeterSurda commented

2016-05-04 22:37:00 +02:00

(Migrated from github.com)

~~Go to this src/bitmsghash directory and do "gmake". This will build the C PoW module and it will be used instead of the Python-based PoW which forks.~~ The module builds with adding a minor ifdef, but it looks like it does not produce correct results because the messages send with this enabled don't arrive.

~~Go to this src/bitmsghash directory and do "gmake". This will build the C PoW module and it will be used instead of the Python-based PoW which forks.~~ The module builds with adding a minor ifdef, but it looks like it does not produce correct results because the messages send with this enabled don't arrive.

PeterSurda commented

2017-02-26 12:46:59 +01:00

(Migrated from github.com)

Ok, so the first ones (which are actually two different ones) have been fixed. The first of those two was a locking / thread synchronising bug. The second of them was more like a warning that indicated it it sometimes sends data between threads too early, but I fixed that too (or I think I fixed it, it's not complaining anyway).

Namecoin reporting was fixed too.

Fix for the last one I'll commit soon.

Ok, so the first ones (which are actually two different ones) have been fixed. The first of those two was a locking / thread synchronising bug. The second of them was more like a warning that indicated it it sometimes sends data between threads too early, but I fixed that too (or I think I fixed it, it's not complaining anyway). Namecoin reporting was fixed too. Fix for the last one I'll commit soon.

PeterSurda commented

2017-02-26 13:05:24 +01:00

(Migrated from github.com)

So I tested it on FreeBSD 11 and it works fine, both the socket handler and the C PoW.

This repo is archived. You cannot comment on issues.