2017-06-29 13:24 ACST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000607Other Unix PortBugpublic2016-11-25 02:01
ReporterDavid McKenna 
Assigned Topsmedley 
PrioritynormalSeveritymajorReproducibilityrandom
StatusassignedResolutionopen 
PlatformIntel i3 H55OSeCSOS Version2.1
Summary0000607: Tor occasionally exits
Description  Seemingly randomly, Tor will close. There does not seem to be any particular activity that causes it, since I can restart it and continue right where I left off. Sometimes I can go for an hour or more before it happens, sometimes it happens a couple of times within 5 minutes.
Additional InformationThe log file always has these lines as the last entries after an exit:

Apr 12 15:34:40.000 [warn] Warning from libevent: select: Bad address
Apr 12 15:34:40.000 [err] libevent call with select failed: Bad address [14]
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0002721

psmedley (administrator)

Please test with 0.2.4.21 which I uploaded yesterday. I built this one without -Zhighmem which should take care of this

~0002724

David McKenna (reporter)

Thanks, Paul! I'll use it for a few days and report back....

~0002725

David McKenna (reporter)

I have been using the new Tor for a couple of days now and have only had 2 exits - much better than before.

 Up to now I have set my browser to use Tor as a Socks4 proxy - maybe not correct? I have switched to Socks5 and will see if that helps at all...

~0002726

David McKenna (reporter)

Socks5 seems a bit faster and I have only had 1 exit using it so far. Now I started using the new port of Vidalia... I like it so far! Will report back on that....

~0002727

David McKenna (reporter)

Vidalia is working great... no exits so far (tor is started as a daemon). I managed to get a relay working and decided to set up a tor bridge on my OS/2 server. Will see how long it stays up....

~0002728

David McKenna (reporter)

Lasted about 18 hours...

~0002729

psmedley (administrator)

Any error logs?

~0002730

David McKenna (reporter)

Just uploaded (tor-log.txt) the last 10 minutes or so of a debug log of Tor with Vidalia running a bridge just before it exited. 18 hours seems pretty consistent for each session before exiting...

~0002731

gianfli (reporter)

Last edited: 2014-05-08 21:32

View 2 revisions

Also for me, the same before exit (however quite rare):
mag 08 11:15:20.888 [Notifica] Bootstrapped 90%: Establishing a Tor circuit.
mag 08 11:15:21.706 [Notifica] Tor has successfully opened a circuit. Looks like client functionality is working.
mag 08 11:15:21.706 [Notifica] Bootstrapped 100%: Done.
mag 08 11:16:12.002 [Notifica] New control connection opened.
mag 08 11:16:31.412 [Avvertimento] Warning from libevent: select: Bad address
mag 08 11:16:31.412 [Errore] libevent call with select failed: Bad address [11]

~0002732

psmedley (administrator)

gianfli: that error is with tor 0.2.4.20 or 0.2.4.21?

~0002734

gianfli (reporter)

No more sure which one, i'll test both again, as soon as occurr.

~0002737

gianfli (reporter)

Found an old log (04/05/2014):
mag 04 14:14:48.478 [Notifica] Tor v0.2.4.21 (git-505962724c05445f) running on OS/2 with Libevent 2.0.21-stable and OpenSSL 1.0.1g.
mag 04 14:14:48.484 [Notifica] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
mag 04 14:14:48.484 [Notifica] Read configuration file "C:\HOME\DEFAULT\.vidalia\torrc".
mag 04 14:14:48.484 [Avvertimento] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible.
mag 04 14:14:48.486 [Notifica] Opening Socks listener on 127.0.0.1:9050
mag 04 14:14:48.486 [Notifica] Opening Control listener on 127.0.0.1:9051
mag 04 14:15:20.870 [Notifica] Parsing GEOIP IPv4 file C:/usr/local/share/tor/geoip.
mag 04 14:15:20.872 [Notifica] We now have enough directory information to build circuits.
mag 04 14:15:20.888 [Notifica] Bootstrapped 80%: Connecting to the Tor network.
mag 04 14:15:20.888 [Notifica] New control connection opened.
mag 04 14:15:20.888 [Notifica] Bootstrapped 85%: Finishing handshake with first hop.
mag 04 14:15:20.888 [Notifica] Bootstrapped 90%: Establishing a Tor circuit.
mag 04 14:15:21.706 [Notifica] Tor has successfully opened a circuit. Looks like client functionality is working.
mag 04 14:15:21.706 [Notifica] Bootstrapped 100%: Done.
mag 04 14:16:11.455 [Notifica] New control connection opened.
mag 04 14:16:12.002 [Notifica] New control connection opened.
mag 04 14:16:31.412 [Avvertimento] Warning from libevent: select: Bad address
mag 04 14:16:31.412 [Errore] libevent call with select failed: Bad address [14]

~0002765

David McKenna (reporter)

Last edited: 2014-06-25 09:21

View 2 revisions

I have not had a crash in my tor client for a couple of weeks since using 'execmode -sp' on tor.exe to force it to one CPU. It doesn't help my bridge though, that still only lasts about 18 hours (at most).


 Any chance you could compile tor 0.2.4.22? It has some memory leak fixes that may help the bridge (I hope).

~0002766

David McKenna (reporter)

Jeez... scratch that last comment... my client just crashed twice in 10 minutes (libevent: select: bad address)...

~0002767

psmedley (administrator)

sounds like I need to try and work out why libevent is giving a bad address on select()....

Will build latest tor anyway

~0002771

psmedley (administrator)

I might have fixed the libevent issue.

tor 0.2.4.22 is at http://smedley.id.au/tmp/tor-0.2.4.22-os2-20140626.zip (not tested here yet)

~0002772

David McKenna (reporter)

Thanks Paul! I set up my client last night and so far it is working well. I'll let you know if anything comes up...

  I set up the bridge (on a different machine),and after connecting to the tor network, I start getting these warnings:

Jun 26 17:22:55.746 [Warning] Couldn't construct socketpair for cpuworker: Bad address
Jun 26 17:22:55.746 [Warning] Cpuworker spawn failed. Will try again later.

  So far it hasn't crashed, but about every minute it posts this warning.

~0002775

David McKenna (reporter)

The client is still running, but the bridge only lasted about 18 hours, so no change there except for the new warnings, and the bridge never gets connected (it did connect in the last version).

~0002779

David McKenna (reporter)

Just got the dreaded libevent: select: bad address exit :-( using 0.2.4.22.

~0002781

David McKenna (reporter)

Paul,

  I downloaded and installed the shared dll version of tor you emailed me about. Unfortunately, the behavior is the same as the earlier version - in this case it exited after about 5 hours with

[warn] Warning from libevent: select: Bad address
[err] libevent call with select failed: Bad address [14]

~0002816

David McKenna (reporter)

Hi Paul,

 There is a new version of Tor that blocks a new attack on the tor network recently discovered that they are recommending all users upgrade to. Any chance you could build it?

~0002817

psmedley (administrator)

Not tested, but http://smedley.id.au/tmp/tor-0.2.4.23-os2-20140815.zip

~0002822

David McKenna (reporter)

Thanks Paul! So far it seems to work at least as good as the previous version. A new PThread has been provided by Netlabs that increases the default stack size (from 64k to 2M) that may help with the 'Bad Address' error - we'll see. I haven't gotten that error yet with this new version.

  Still get the 'CPU worker spawn failed' error when trying to set up a bridge. Uploaded a debug log for that if it is any help...

~0002823

David McKenna (reporter)

Oh well... running a client I got the 'Bad Address' error 3 times today :-(

~0002851

psmedley (administrator)

won't fix the crash, but http://smedley.id.au/tor/tor-0.2.4.24-os2-20141006.zip

~0002864

David McKenna (reporter)

Thanks again! Been using it a couple of days and it works as well as the last one.... still can't get a bridge working though....

~0002905

psmedley (administrator)

https://dl.dropboxusercontent.com/u/76425158/tor-0.2.5.10-os2-20141108.zip - I switched some malloc calls to _lmalloc which might help the bad address errors

~0002907

David McKenna (reporter)

Thanks Paul! It seems to work fine as a client, but I can't get a bridge or relay to work - it just crashes without useful log info. I probably need to spend some time reading about the new version. I also can't get Dave Y's SeaMonkey 2.21 to use it or any version of Tor(errors saying website is available, but can't connect) but the official Firefox 24 works fine. I'll keep you posted...

~0002908

psmedley (administrator)

https://dl.dropboxusercontent.com/u/76425158/tor-0.2.5.10-os2-20141109.zip

Slight tweak to libevent to add support to set non-blocking mode on sockets which may help with the select error. I wouldn't expect a bad address error but it's worth a shot.

~0002910

David McKenna (reporter)

OK... thanks. I'll switch over to this new one. The other one has worked well as a client - only about 24 hours though...

~0002912

David McKenna (reporter)

Hate to say it, but I just got the 'libevent: select: Bad address' error :-(

~0002913

psmedley (administrator)

to be honest, I wasn't confident....

~0003046

psmedley (administrator)

I added tor 0.2.6.10 to my site today, probably won't fix this issue though...

~0003048

David McKenna (reporter)

Thanks Paul! This version seems to work with the same caveats as before, although I have not got a 'Bad Address' error yet...

~0003105

psmedley (administrator)

Hi guys - http://smedley.id.au/tmp/tor-0.2.7.6-os2-20160127.zip might fix the 'bad address' errors.

I got a copy of a set of diffs for libevent from dmitry that he's using for firefox. It includes a set of fixes for EBADF (bad address).

If you guys can confirm stability is improved I'll add this build to my site.

~0003106

David McKenna (reporter)

Thanks Paul (and Dmitriy)! I'll let you know what I see....

~0003107

David McKenna (reporter)

Paul, so far have not had any 'bad address' exits (fingers crossed). This build seems to connect a bit faster than others too. One thing new I see is warnings in the startup log:

Jan 28 16:12:13.648 [Warning] tor_addr_is_internal_(): Bug: tor_addr_is_internal() called from src/common/address.c:1650 with a non-IP address of type 49 (on Tor 0.2.7.6 )
Jan 28 16:12:13.648 [Warning] tor_addr_is_internal_(): Bug: tor_addr_is_internal() called from src/common/address.c:1650 with a non-IP address of type 49 (on Tor 0.2.7.6 )

 Vidalia also indicates these warnings as software errors and recommends reporting to the Tor authors. They come up every once in a while, but so far do not seem to be harmful (at least to the connection)

~0003108

David McKenna (reporter)

Paul,

  Sorry to say I got the 'Bad Address' error today with version 0.2.7.6. In addition to the warning I mention above, I also see this warning:

Jan 31 15:36:28.809 [Warning] Path for DataDirectory (D:/HOME/DEFAULT/.tor) is relative and will resolve to D:/HOME/DEFAULT/.tor. Is this what you wanted?

  It doesn't seem to affect anything, but it is strange because in the 'torrc' file I explicitly call out:

DataDirectory D:\HOME\DEFAULT\.tor

  but tor mangles the slashes somehow. Other directory directives in the 'torrc' file (like GeoIPFile C:\usr\local\share\tor\geoip) don't have a problem like this.

~0003118

psmedley (administrator)

Last edited: 2016-09-12 19:29

View 2 revisions

Updated build 0.2.8.7 - requires latest libcx0.dll from rpm/yum - hopefully http://rpm.netlabs.org/release/00/zip/libcx-0_2_1-1_oc00.zip should work, but might need http://rpm.netlabs.org/test/tlx4.zip

http://smedley.id.au/tmp/tor-0.2.8.7-os2-20160912.zip

Dave - let me know if the warning about relative paths still occurs

~0003119

David McKenna (reporter)

Thanks Paul!

  This definitely needs tlx4.zip. Won't start with the 'official' libcx. I do still get the relative paths warning for the data directory path only like this:

Sep 17 14:27:10.422 [Warning] Path for DataDirectory (D:/HOME/DEFAULT/.tor) is relative and will resolve to D:/HOME/DEFAULT/.tor. Is this what you wanted?

  I'm guessing it has something to do with my %HOME% directory not being on the same drive (D) as my UNIXROOT (C).

  Been running this version for a few days and it seems to get up to full speed much faster. It also seems much more stable, although I did have it crash once with a select() error that seemed slightly different (unfortunately I didn't capture it because I was running tor without realizing it wasn't creating a log file, only stdout to Vidalia - since corrected). Still haven't tried setting up a bridge. If anything crops up I'll let you know....

~0003120

psmedley (administrator)

OK now that I read the code properly, I see why tor thought the path was relative. Whilst we were using the win32 code path, that code path only looked for x:\ in a path, not x:/

Anyhow, http://smedley.id.au/tmp/tor-0.2.8.7-os2-20160921.zip should address....

~0003121

David McKenna (reporter)

Thanks Again, Paul!That took care of the warning about the DataDirectory.

  The first time I ran this I got the following log:

Sep 21 06:28:20.000 [notice] Tor 0.2.8.7 opening log file.
Sep 21 06:28:20.063 [notice] Tor v0.2.8.7 running on OS/2 with Libevent 2.0.21-stable, OpenSSL 1.0.1o and Zlib 1.2.5.
Sep 21 06:28:20.063 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 21 06:28:20.069 [notice] Read configuration file "C:\usr\local\etc\tor\torrc".
Sep 21 06:28:20.083 [notice] Opening Socks listener on 127.0.0.1:9050
Sep 21 06:28:20.083 [notice] Opening Control listener on 127.0.0.1:9051
Sep 21 06:28:20.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Sep 21 06:28:20.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Sep 21 06:28:21.000 [notice] Bootstrapped 0%: Starting
Sep 21 06:28:26.000 [notice] New control connection opened from 127.0.0.1.
Sep 21 06:28:26.000 [notice] Bootstrapped 5%: Connecting to directory server
Sep 21 06:28:26.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Sep 21 06:28:27.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Sep 21 06:28:27.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Sep 21 06:28:27.000 [notice] Bootstrapped 25%: Loading networkstatus consensus
Sep 21 06:28:32.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Sep 21 06:28:32.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 5454/7191, and can only build 45% of likely paths. (We have 75% of guards bw, 75% of midpoint bw, and 78% of exit bw = 45% of path bw.)
Sep 21 06:28:32.000 [notice] Bootstrapped 71%: Loading relay descriptors
Sep 21 06:28:33.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Sep 21 06:28:34.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Sep 21 06:28:35.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 21 06:28:35.000 [notice] Bootstrapped 100%: Done
Sep 21 06:29:37.000 [warn] Warning from libevent: select: Bad address
Sep 21 06:29:37.000 [err] libevent call with select failed: Bad address [14]

 This is exactly what happened the first time I ran the last version. Every time after that I have had no problems... maybe a clue or just coincidence? Usually my log looks like this:

Sep 21 16:17:22.365 [Notice] Tor v0.2.8.7 running on OS/2 with Libevent 2.0.21-stable, OpenSSL 1.0.1o and Zlib 1.2.5.
Sep 21 16:17:22.369 [Notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 21 16:17:22.369 [Notice] Read configuration file "C:\usr\local\etc\tor\torrc".
Sep 21 16:17:22.380 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 21 16:17:22.380 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 21 16:17:22.406 [Notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Sep 21 16:17:22.511 [Notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Sep 21 16:17:23.997 [Notice] Bootstrapped 0%: Starting
Sep 21 16:17:29.443 [Notice] Bootstrapped 80%: Connecting to the Tor network
Sep 21 16:17:29.443 [Notice] New control connection opened from 127.0.0.1.
Sep 21 16:17:29.443 [Notice] Bootstrapped 85%: Finishing handshake with first hop
Sep 21 16:17:29.814 [Notice] Bootstrapped 90%: Establishing a Tor circuit
Sep 21 16:17:30.313 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 21 16:17:30.313 [Notice] Bootstrapped 100%: Done

~0003122

David McKenna (reporter)

Hi Paul,

 Just updated to the new libcx (ver 0.3) and now I am seeing these errors in the log:

Sep 22 20:09:18.787 [Warning] Could not mmap file "D:/HOME/DEFAULT/.tor/cached-microdescs": Unknown error 84
Sep 22 20:09:18.787 [Warning] Could not mmap file "D:/HOME/DEFAULT/.tor/cached-microdescs": Unknown error 84
Sep 22 20:09:18.787 [Error] Couldn't map file that we just wrote to D:/HOME/DEFAULT/.tor/cached-microdescs!

  It seems to be working though....

~0003123

psmedley (administrator)

Last edited: 2016-09-23 19:29

View 2 revisions

Might need a rebuild against latest libcx....

htp://smedley.id.au/tmp/tor-0.2.8.7-os2-20160923.zip

~0003124

David McKenna (reporter)

Thanks again... no change though, still get the warning and error listed above.

~0003125

psmedley (administrator)

ok - will have to report it to Dmitry

~0003126

David McKenna (reporter)

Paul,

  Was playing around with Tor this morning and found a way to get rid of the error I reported.

  When tor starts it creates a bunch of files in %HOME%\.tor (the default data file location), including 'cached-microdescs' mentioned in the error above. When Tor stops all of these files are left behind. If I delete them before starting Tor, then there are no errors reported at startup. So it seems the problem is that 'cached-microdescs' already exists when Tor starts and that precipitates the error. As a bonus, Tor starts about 3 times faster (in 0000005:0000010 seconds instead of 0000015:0000030) if those files are not there.

  This makes me wonder if maybe Tor is supposed to delete those file at close but doesn't due to a bug? In any case I work around the issue now by directing Tor to put data files on my RAM drive (using the 'DataDirectory' directive in my torrc file) so they are deleted when I boot.

~0003127

David McKenna (reporter)

Well... been running Tor for a couple of hours and I have seen the error again:

Sep 24 12:28:36.844 [Warning] Could not mmap file "Z:/Home/.tor/cached-microdescs": Unknown error 84
Sep 24 12:28:36.846 [Error] Couldn't map file that we just wrote to Z:/Home/.tor/cached-microdescs!

  So it seems this file is re-written periodically by Tor anyway.

~0003128

psmedley (administrator)

some more path related changes, including changing the rename code to be like _WIN32 and remove the file first - a guess for the above problem but shouldn't hurt...

http://smedley.id.au/tmp/tor-0.2.8.7-os2-20161001.zip

~0003129

David McKenna (reporter)

OK, thanks! This is an improvement, but I still get the above mmap file warning and errors, just not as frequently. I started and stopped tor 10 times in sequence, and I saw the error every other time - that is 5 out of 10 times, I got the error on startup (with the cached-microdescs file present every time). I used to get it every time on startup...

~0003130

David McKenna (reporter)

I've gone back to the previous (20160923) version. For some reason with the 20161001 version I sometimes can't connect to websites. No errors are given from tor, but I just don't connect. No problem connecting with 20160923....

~0003131

David McKenna (reporter)

Paul,

  I've been getting warnings from Tor to update because of security fixes. Any chance for a new build when you have some time? I notice there is also a new libcx too - maybe helps some of the problems...

~0003132

psmedley (administrator)

http://smedley.id.au/tmp/tor-0.2.8.9-os2-20161124.zip :) not tested.


Build against libcx 0.4 (self built, but should be the same as the released one)

~0003133

David McKenna (reporter)

Thanks Paul! I have a similar problem with this one as with the 1001 build... tor starts fine, and the logs show it is connected to the network without error, but I can't get a connection with the browser. It just sits there saying 'connecting' until it times out. I go back to the 0923 build and it works again...
+Notes

-Issue History
Date Modified Username Field Change
2014-04-13 05:53 David McKenna New Issue
2014-04-22 08:04 psmedley Note Added: 0002721
2014-04-22 08:04 psmedley Assigned To => psmedley
2014-04-22 08:04 psmedley Status new => feedback
2014-04-23 07:36 David McKenna Note Added: 0002724
2014-04-23 07:36 David McKenna Status feedback => assigned
2014-04-27 23:29 David McKenna Note Added: 0002725
2014-05-03 07:46 David McKenna Note Added: 0002726
2014-05-05 01:37 David McKenna Note Added: 0002727
2014-05-05 20:21 David McKenna Note Added: 0002728
2014-05-07 19:24 psmedley Note Added: 0002729
2014-05-08 08:11 David McKenna File Added: tor-log.txt
2014-05-08 08:13 David McKenna Note Added: 0002730
2014-05-08 21:27 gianfli Note Added: 0002731
2014-05-08 21:32 gianfli Note Edited: 0002731 View Revisions
2014-05-09 07:27 psmedley Note Added: 0002732
2014-05-10 04:53 gianfli Note Added: 0002733
2014-05-10 05:01 gianfli Note Deleted: 0002733
2014-05-10 05:11 gianfli Note Added: 0002734
2014-05-12 01:01 gianfli Note Added: 0002737
2014-06-25 09:20 David McKenna Note Added: 0002765
2014-06-25 09:21 David McKenna Note Edited: 0002765 View Revisions
2014-06-25 09:57 David McKenna Note Added: 0002766
2014-06-25 11:58 psmedley Note Added: 0002767
2014-06-26 18:55 psmedley Note Added: 0002771
2014-06-27 06:57 David McKenna Note Added: 0002772
2014-06-29 09:04 David McKenna Note Added: 0002775
2014-07-01 08:50 David McKenna Note Added: 0002779
2014-07-15 08:03 David McKenna Note Added: 0002781
2014-08-15 10:32 David McKenna Note Added: 0002816
2014-08-15 19:00 psmedley Note Added: 0002817
2014-08-17 00:13 David McKenna Note Added: 0002822
2014-08-17 00:13 David McKenna File Added: bridge-0.2.23-debug.log
2014-08-17 13:36 David McKenna Note Added: 0002823
2014-10-06 07:23 psmedley Note Added: 0002851
2014-10-10 22:05 David McKenna Note Added: 0002864
2014-11-08 18:52 psmedley Note Added: 0002905
2014-11-09 11:31 David McKenna Note Added: 0002907
2014-11-09 14:59 psmedley Note Added: 0002908
2014-11-10 02:00 David McKenna Note Added: 0002910
2014-11-10 22:52 David McKenna Note Added: 0002912
2014-11-11 19:05 psmedley Note Added: 0002913
2015-08-10 10:17 psmedley Note Added: 0003046
2015-08-11 06:34 David McKenna Note Added: 0003048
2016-01-27 19:06 psmedley Note Added: 0003105
2016-01-27 22:39 David McKenna Note Added: 0003106
2016-01-29 08:36 David McKenna Note Added: 0003107
2016-02-01 07:13 David McKenna Note Added: 0003108
2016-09-12 19:26 psmedley Note Added: 0003118
2016-09-12 19:29 psmedley Note Edited: 0003118 View Revisions
2016-09-18 04:10 David McKenna Note Added: 0003119
2016-09-21 19:23 psmedley Note Added: 0003120
2016-09-22 06:01 David McKenna Note Added: 0003121
2016-09-23 09:43 David McKenna Note Added: 0003122
2016-09-23 19:00 psmedley Note Added: 0003123
2016-09-23 19:29 psmedley Note Edited: 0003123 View Revisions
2016-09-23 19:56 David McKenna Note Added: 0003124
2016-09-24 07:20 psmedley Note Added: 0003125
2016-09-25 00:53 David McKenna Note Added: 0003126
2016-09-25 02:52 David McKenna Note Added: 0003127
2016-10-01 13:24 psmedley Note Added: 0003128
2016-10-03 02:48 David McKenna Note Added: 0003129
2016-10-05 07:00 David McKenna Note Added: 0003130
2016-11-24 08:48 David McKenna Note Added: 0003131
2016-11-24 19:31 psmedley Note Added: 0003132
2016-11-25 02:01 David McKenna Note Added: 0003133
+Issue History