Freezes upon starting proof of work #312

New Issue

2013-07-17T23:16:45+02:00

fiatflux commented

2013-07-17 23:16:45 +02:00

(Migrated from github.com)

When sending a message, everything freezes (deadlocks?) upon trying to do proof of work. I believe this is due to a very recent commit, but I won't have time to verify that until tomorrow.

Searching the forum suggests it's not just me:
https://bitmessage.org/forum/index.php/topic,2736.0.html

When sending a message, everything freezes (deadlocks?) upon trying to do proof of work. I believe this is due to a very recent commit, but I won't have time to verify that until tomorrow. Searching the forum suggests it's not just me: https://bitmessage.org/forum/index.php/topic,2736.0.html

fiatflux commented

2013-07-18 11:25:52 +02:00

(Migrated from github.com)

This is really bizarre.

The hang appears to happen upon creating the multiprocessing.Pool at proofofwork.py:55.

I have this problem running even old versions of PyBitmessage (which I know to have worked previously) on:
Linux 3.9.9-1-ARCH installed on 2013-06-03 (same as I had installed when I had PyBitmessage working fine)
Python 2.7.5 packaged on 2013-05-12 (same as I had installed when I had PyBitmessage working fine).
None of my headers nor python libraries have changed since 2013-06-03 either.

And the plot thickens. Running all the same non-PyBitmessage software, I tried doing simple multiprocessing.Pool tasks in a separate project, with no problems. I can't think of any way PyBitmessage is using multiprocessing in an unusual manner...

This is really bizarre. The hang appears to happen upon creating the multiprocessing.Pool at proofofwork.py:55. I have this problem running even old versions of PyBitmessage (which I know to have worked previously) on: Linux 3.9.9-1-ARCH installed on 2013-06-03 (same as I had installed when I had PyBitmessage working fine) Python 2.7.5 packaged on 2013-05-12 (same as I had installed when I had PyBitmessage working fine). None of my headers nor python libraries have changed since 2013-06-03 either. And the plot thickens. Running all the same non-PyBitmessage software, I tried doing simple multiprocessing.Pool tasks in a separate project, with no problems. I can't think of any way PyBitmessage is using multiprocessing in an unusual manner...

fiatflux commented

2013-07-22 23:32:59 +02:00

(Migrated from github.com)

One more tiny layer of this onion unpeeled: the hangup occurs while starting the result handler in Pool.init

What's odd is that I don't see anything special about that Thread as opposed to the ones created immediately before it.

One more tiny layer of this onion unpeeled: the hangup occurs while starting the result handler in Pool.**init** What's odd is that I don't see anything special about that Thread as opposed to the ones created immediately before it.

fiatflux commented

2013-08-10 14:10:22 +02:00

(Migrated from github.com)

Oh, of course! The bloody problem is just gevent! (So that's why poking around in the subprocess module source wasn't helping me...)

For now, y'all can just uninstall gevent and _doFastPow should work fine. This weekend I guess I'll submit a patch to disable gevent on Linux, but this bug with gevent really should be identified for the good of everyone.

Oh, of course! The bloody problem is just gevent! (So that's why poking around in the subprocess module source wasn't helping me...) For now, y'all can just uninstall gevent and _doFastPow should work fine. This weekend I guess I'll submit a patch to disable gevent on Linux, but this bug with gevent really should be identified for the good of everyone.

remyroy commented

2013-08-15 20:52:37 +02:00

(Migrated from github.com)

On CentOS, I can confirm this using gevent. Whenever I tried to send a message with gevent in daemon mode, PyBitmessage would stop responding. Whenever I tried to restart, it would freeze soon after restart.

Removing ~/.config/PyBitmessage/messages.dat would solve this problem until I tried to send a new message again.

For me, the workaround to be able to send message was to remove gevent. There is most likely a problem with the gevent implementation of sending messages.

I tested this with 0.3.5 (97df9e04f1) and latest (49d16a502e) and both of them had the problem.

On CentOS, I can confirm this using gevent. Whenever I tried to send a message with gevent in daemon mode, PyBitmessage would stop responding. Whenever I tried to restart, it would freeze soon after restart. Removing ~/.config/PyBitmessage/messages.dat would solve this problem until I tried to send a new message again. For me, the workaround to be able to send message was to remove gevent. There is most likely a problem with the gevent implementation of sending messages. I tested this with 0.3.5 (97df9e04f13c8450e62d97f0fe50d1264f39488b) and latest (49d16a502edea29ce96530683906ed4744087c11) and both of them had the problem.

fiatflux commented

2013-08-15 23:59:24 +02:00

(Migrated from github.com)

@remyroy Thanks for reporting. See discussion for #398 the background cause and planned steps.

This repo is archived. You cannot comment on issues.