Version 0.6.0 prints a lot of errors #854
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-20#854
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Many error messages like these are printed during the runtime:
Also in the beginning this error message is printed:
FreeBSD-10.3
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:I just noticed it's for netbsd so ignore it.f3a1af0f32
. Try it and let me know if it helps.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.
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.
I don't know what signal was. But for example SIGCHLD can cause this if the process starts child processes.
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.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.
So I tested it on FreeBSD 11 and it works fine, both the socket handler and the C PoW.