Latest Version 0.6.1 message queued freeze issue #894

New Issue

2016-08-27T03:54:49+02:00

ghost commented

2016-08-27 03:54:49 +02:00

(Migrated from github.com)

Just after upgrading and opening Bitmessage, everytime i send a message, just after sending the message, the whole window freezes while it says at the bottom left hand corner 'Message queued'.
I think until the message is actually sent, it will freeze the whole window, then will unfreeze but takes long.
The reason why my message takes a bit too long to go through is because i havent fully allowed Bitmessage through the firewall, so i should be getting 8 connections only which i am fine with. Though the version before 0.6.1 did not freeze even though my message was queued. Is this a new bug now?

I am using Ubuntu 14.04, and downloaded with git clone.

Just after upgrading and opening Bitmessage, everytime i send a message, just after sending the message, the whole window freezes while it says at the bottom left hand corner 'Message queued'. I think until the message is actually sent, it will freeze the whole window, then will unfreeze but takes long. The reason why my message takes a bit too long to go through is because i havent fully allowed Bitmessage through the firewall, so i should be getting 8 connections only which i am fine with. Though the version before 0.6.1 did not freeze even though my message was queued. Is this a new bug now? I am using Ubuntu 14.04, and downloaded with git clone.

PeterSurda commented

2016-08-27 09:20:36 +02:00

(Migrated from github.com)

What type of hardware do you have and which PoW module are you using?

PeterSurda commented

2016-08-27 09:24:14 +02:00

(Migrated from github.com)

I can reproduce this on 16.04, it's probably something with the multiprocessing scheduler. Build the C PoW module (execute "make" in src/bitmsghash) and restart PyBitmessage.

bmng-dev commented

2016-08-27 13:32:57 +02:00

(Migrated from github.com)

PoW is always performed in a different thread than the GUI so at worst you should experience a stuttering/jerky GUI. The behavior you describe seems correlated to the recent change to the pure python Fast PoW function where signal manipulation is performed just before and after the CPU intensive work. Unfortunately signal manipulation is only meant to be done from the main thread. From the signal module docs:

Some care must be taken if both signals and threads are used in the same program. The fundamental thing to remember in using signals and threads simultaneously is: always perform signal() operations in the main thread of execution. Any thread can perform an alarm(), getsignal(), pause(), setitimer() or getitimer(); only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). This means that signals can’t be used as a means of inter-thread communication. Use locks instead.

PoW is always performed in a different thread than the GUI so at worst you should experience a stuttering/jerky GUI. The behavior you describe seems correlated to the recent change to the pure python Fast PoW function where signal manipulation is performed just before and after the CPU intensive work. Unfortunately signal manipulation is only meant to be done from the main thread. From the [signal](https://docs.python.org/2/library/signal.html) module docs: > Some care must be taken if both signals and threads are used in the same program. The fundamental thing to remember in using signals and threads simultaneously is: always perform signal() operations in the main thread of execution. Any thread can perform an alarm(), getsignal(), pause(), setitimer() or getitimer(); only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). This means that signals can’t be used as a means of inter-thread communication. Use locks instead.

PeterSurda commented

2016-08-27 15:28:33 +02:00

(Migrated from github.com)

Thank you @bmng-dev , I don't know what I would do without you. If I remember right, the changes actually remove the signal handler before starting the PoW, because the PoW was catching signals that were supposed to be processed by the main thread and it caused freezes during the shutdown. I'll rework it.

Thank you @bmng-dev , I don't know what I would do without you. If I remember right, the changes actually **remove** the signal handler before starting the PoW, because the PoW was catching signals that were supposed to be processed by the main thread and it caused freezes during the shutdown. I'll rework it.

bmng-dev commented

2016-08-27 16:59:45 +02:00

(Migrated from github.com)

The PoW should probably be done in a completely separate process regardless of whether it is pure Python, C, or OpenCL. A simple CLI accepting the hash and target as arguments and printing the nonce before exiting should suffice initially.

bmng-dev commented

2016-08-28 14:12:01 +02:00

(Migrated from github.com)

Okay, the actual issue is NameError: name 'signal' is not defined. The signal module isn't imported. However it is still worth checking if the removal and restoration of the signal handlers works as expected and doesn't cause any issues.

Okay, the actual issue is `NameError: name 'signal' is not defined`. The signal module isn't imported. However it is still worth checking if the removal and restoration of the signal handlers works as expected and doesn't cause any issues.

ghost commented

2016-08-29 03:23:53 +02:00

(Migrated from github.com)

@PeterSurda im not too sure what you mean about what PoW module im using? But im glad you have reproduced the problem and that this will be fixed.

PeterSurda commented

2016-08-29 05:30:43 +02:00

(Migrated from github.com)

@Beast141 : as I said, build the C PoW module by executing "make" in src/bitmsghash, you don't have to wait fo the fix of the python PoW. That one is only for situations where for some reason you can't use the C one (and it's slower too). I already spent several hours on that so it may take a while.

You can check which PoW you're using by clicking "Help" and "Contact support". It will tell you if C and OpenCL PoW is available.

@Beast141 : as I said, build the C PoW module by executing "make" in src/bitmsghash, you don't have to wait fo the fix of the python PoW. That one is only for situations where for some reason you can't use the C one (and it's slower too). I already spent several hours on that so it may take a while. You can check which PoW you're using by clicking "Help" and "Contact support". It will tell you if C and OpenCL PoW is available.

PeterSurda commented

2016-08-29 06:19:02 +02:00

(Migrated from github.com)

@bmng-dev I will consider having a separate process, but for the time being I'll try to fix it instead, even though it's a lot of debugging. I now have a semi-working version with the signal handler change removed: the existing signal handler can detect if it's a pool process, it then raises and error which is caught by singleWorker and it can abort cleanly. It doesn't seem to hog the UI anymore. But there is still some work for cleaning it up before I commit it.

The benefit of the patch will be that the daemon can quit more cleanly, and when running the UI and there is pending work, it will ask you whether to wait or not, and can now abort the PoW if you choose so.

@bmng-dev I will consider having a separate process, but for the time being I'll try to fix it instead, even though it's a lot of debugging. I now have a semi-working version with the signal handler change removed: the existing signal handler can detect if it's a pool process, it then raises and error which is caught by singleWorker and it can abort cleanly. It doesn't seem to hog the UI anymore. But there is still some work for cleaning it up before I commit it. The benefit of the patch will be that the daemon can quit more cleanly, and when running the UI and there is pending work, it will ask you whether to wait or not, and can now abort the PoW if you choose so.

This repo is archived. You cannot comment on issues.