Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:03:36Zhttps://gitlab.torproject.org/legacy/trac/-/issues/55MemoryError traceback2020-06-13T14:03:36Zweasel (Peter Palfrader)MemoryError tracebackno idea if it's mixminion's fault, but still, here it is:
Jan 01 01:06:34.260 +0100 [WARN] Couldn't connect to 'winnie' at 64.115.210.23:48099 (fd 7)
Jan 01 01:06:34.261 +0100 [TRACE] DeliveryQueue failed to deliver T+KVMdFF from outgoi...no idea if it's mixminion's fault, but still, here it is:
Jan 01 01:06:34.260 +0100 [WARN] Couldn't connect to 'winnie' at 64.115.210.23:48099 (fd 7)
Jan 01 01:06:34.261 +0100 [TRACE] DeliveryQueue failed to deliver T+KVMdFF from outgoing
Jan 01 01:06:34.263 +0100 [TRACE] (We'll try T+KVMdFF again at 2005-01-01 07:58:54)
Jan 01 01:08:00.397 +0100 [INFO] Downloading directory from http://mixminion.net/directory/Directory.gz
Jan 01 01:08:06.194 +0100 [INFO] Validating directory
Jan 01 01:08:17.903 +0100 [ERROR] Exception while processing; shutting down thread.
Jan 01 01:08:19.722 +0100 [ERROR] Traceback (most recent call last):
File "/home/minion/lib/python2.2/site-packages/mixminion/server/ServerMain.py", line 491, in run
job()
File "/home/minion/lib/python2.2/site-packages/mixminion/server/ServerMain.py", line 838, in c
self.dirClient.updateDirectory()
File "/home/minion/lib/python2.2/site-packages/mixminion/ClientDirectory.py", line 147, in updateDirectory
self.downloadDirectory(timeout=timeout)
File "/home/minion/lib/python2.2/site-packages/mixminion/ClientDirectory.py", line 165, in downloadDirectory
self._downloadDirectory(timeout)
File "/home/minion/lib/python2.2/site-packages/mixminion/ClientDirectory.py", line 256, in _downloadDirectory
self.rescan()
File "/home/minion/lib/python2.2/site-packages/mixminion/ClientDirectory.py", line 359, in rescan
self.__save()
File "/home/minion/lib/python2.2/site-packages/mixminion/ClientDirectory.py", line 397, in __save
writePickled(os.path.join(self.dir, "cache"), data)
File "/home/minion/lib/python2.2/site-packages/mixminion/Common.py", line 616, in writePickled
cPickle.dump(obj, f, 1)
MemoryError
Jan 01 01:08:19.841 +0100 [FATAL] One of our threads has halted; shutting down.
Jan 01 01:08:19.841 +0100 [INFO] Server shutting down
Jan 01 01:08:19.842 +0100 [INFO] Telling cleanup thread to shut down.
Jan 01 01:08:19.843 +0100 [INFO] Cleanup thread shutting down.
Jan 01 01:08:19.844 +0100 [INFO] Telling processing thread to shut down.
Jan 01 01:08:19.845 +0100 [INFO] Telling delivery thread to shut down.
Jan 01 01:08:19.846 +0100 [INFO] Delivery thread shutting down.
Jan 01 01:08:19.846 +0100 [DEBUG] Disabling module DROP
Jan 01 01:08:20.291 +0100 [DEBUG] Syncing statistics to disk
Jan 01 01:08:20.501 +0100 [INFO] Server is shut down
The box isn't out of disk space, no quotas.
[weasel:remop_r:remop_t] minion@constellation:~/miniond$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) 65536
open files (-n) 256
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 16
virtual memory (kbytes, -v) 65536
let me know what else you'ld like to know
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/139decoded binary file differs from the file sent.2020-06-13T13:57:15ZTracdecoded binary file differs from the file sent.Steps to reproduce:
$ xxd -p bad
00000004036261720100002200000000000600a0000000003988000000
0000000000000000000000000000000000
$ mixminion generate-surb -t me@home.net -b -o SURB
$ mixminion send -R SURB -i bad
Wait for return message, ...Steps to reproduce:
$ xxd -p bad
00000004036261720100002200000000000600a0000000003988000000
0000000000000000000000000000000000
$ mixminion generate-surb -t me@home.net -b -o SURB
$ mixminion send -R SURB -i bad
Wait for return message, feed it to
`mixminion decode -o out'. The decoded file contains an extraneous leading 0x0a. I noticed this while playing with nym3 (the binary file sent is a reply message from the server to the client with a CREATED and a STATUS part).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: lfousseNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/206Failure to create user data on single-users win32 systems2020-06-13T13:57:16ZTracFailure to create user data on single-users win32 systemsHi,
There is a problem when running mixminion on single-user win32 systems. Some systems have never been setup with any accounts at all. When mixminion tries to place the user data in the expected user directory (c:\documents and settin...Hi,
There is a problem when running mixminion on single-user win32 systems. Some systems have never been setup with any accounts at all. When mixminion tries to place the user data in the expected user directory (c:\documents and settings\[username]), it fails because the directory does not exist. It is customary on these systems to put the user data in the application's directory.
We have a work-around, discovered by Ed Langenback, that if you put a subdir in the mixminion dir called "~" (no quotes) it will fool mixminion into using that directory for user data. One requirement in using this is that mixminion must always be started and used from it own directory.
[Automatically added by flyspray2trac: Operating System: Windows]
**Trac**:
**Username**: quicksilverNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/213Unhandled socket.error from getpeername()2020-06-13T13:57:16ZNick MathewsonUnhandled socket.error from getpeername()Reported by Laurent Fousse.
Sometimes, the getpeername() in _newMMTPConnection() in MMTPServer.py throws a socket.error that nobody catches.
This makes the process shut down: that's no good. It should mark the connection as failed, an...Reported by Laurent Fousse.
Sometimes, the getpeername() in _newMMTPConnection() in MMTPServer.py throws a socket.error that nobody catches.
This makes the process shut down: that's no good. It should mark the connection as failed, and try again later.
[Automatically added by flyspray2trac: Operating System: All]0.0.8 finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/214IOError when flushing log2020-06-13T13:57:16ZNick MathewsonIOError when flushing logReported by Marco Calamari.
Sometimes, it seems, trying to flush the logfile descriptor gives an IOError (errno 5: EIO).
I have no idea why this is happening, but it has been reported on multiple hosts.
File "/usr/lib/python2.3/si...Reported by Marco Calamari.
Sometimes, it seems, trying to flush the logfile descriptor gives an IOError (errno 5: EIO).
I have no idea why this is happening, but it has been reported on multiple hosts.
File "/usr/lib/python2.3/site-packages/mixminion/TLSConnection.py",
line 435, in process
self.__close(gotClose=1)
File "/usr/lib/python2.3/site-packages/mixminion/TLSConnection.py",
line 256, in __close
LOG.warn("Couldn't connect to %s",self.address)
File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
1010, in warn
self.log("WARN", message, *args)
File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
974, in log
self._log(severity, message, args)
File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
995, in _log
h.write(severity, m)
File "/usr/lib/python2.3/site-packages/mixminion/Common.py", line
841, in write
self.file.flush()
IOError: [Errno 5] Input/output error
Oct 17 07:58:50.750 +0200 [FATAL] Shutting down because of exception:
exceptions.IOError
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/215mixminion creates path shorter than 3 nodes2020-06-13T13:57:16ZTracmixminion creates path shorter than 3 nodesI was testing the new 0.0.8alpha1 server on laforge. To my
understanding a message should pass at least three nodes to ensure my
anonymity. I wanted to test the laforge node, so I sent the messages
with -P laforge,~2 ( send the message ...I was testing the new 0.0.8alpha1 server on laforge. To my
understanding a message should pass at least three nodes to ensure my
anonymity. I wanted to test the laforge node, so I sent the messages
with -P laforge,~2 ( send the message through laforge and about two
other nodes). As you can see in the output below the mixminion client
selected to send my message through laforge and use laforge a a swap
point. So the message will only go through 1 node. In my opinion the
~<number> option should calculate a minimum number of nodes so a
message will go through at least three nodes. I have verified the bug on windows and FreeBSD, and I assume that the bug exists on all platforms.
D:\mixminion\Mixminion-0.0.7.1>mixminion.exe send -t smtp:simono@ostengaard.dk -
i data -P laforge,~2
Mixminion version 0.0.7.1
This software is for testing purposes only. Anonymity is not guaranteed.
Dec 04 19:39:37.789 +0100 [INFO] Downloading directory from http://mixminion.net
/directory/Directory.gz
Dec 04 19:39:44.579 +0100 [INFO] Validating directory
Dec 04 19:39:45.139 +0100 [WARN] This software is newer than any version on the
recommended list.
Dec 04 19:39:45.139 +0100 [INFO] Generating payload(s)...
Dec 04 19:39:45.149 +0100 [INFO] Selected path is laforge:laforge
Dec 04 19:39:45.229 +0100 [INFO] Packet queued
Dec 04 19:39:45.229 +0100 [INFO] Connecting...
Dec 04 19:39:47.743 +0100 [INFO] ... 1 sent
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: simono