View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000607 | Other Unix Port | Bug | public | 2014-04-12 20:23 | 2020-08-24 03:07 |
Reporter | David McKenna | Assigned To | psmedley | ||
Priority | normal | Severity | major | Reproducibility | random |
Status | closed | Resolution | fixed | ||
Platform | Intel i3 H55 | OS | eCS | OS Version | 2.1 |
Summary | 0000607: 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 Information | The 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] | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
|
Please test with 0.2.4.21 which I uploaded yesterday. I built this one without -Zhighmem which should take care of this |
|
Thanks, Paul! I'll use it for a few days and report back.... |
|
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... |
|
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.... |
|
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.... |
|
Lasted about 18 hours... |
|
Any error logs? |
|
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... |
|
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] |
|
gianfli: that error is with tor 0.2.4.20 or 0.2.4.21? |
|
No more sure which one, i'll test both again, as soon as occurr. |
|
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] |
|
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). |
|
Jeez... scratch that last comment... my client just crashed twice in 10 minutes (libevent: select: bad address)... |
|
sounds like I need to try and work out why libevent is giving a bad address on select().... Will build latest tor anyway |
|
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) |
|
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. |
|
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). |
|
Just got the dreaded libevent: select: bad address exit :-( using 0.2.4.22. |
|
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] |
|
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? |
|
Not tested, but http://smedley.id.au/tmp/tor-0.2.4.23-os2-20140815.zip |
|
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... |
|
Oh well... running a client I got the 'Bad Address' error 3 times today :-( |
|
won't fix the crash, but http://smedley.id.au/tor/tor-0.2.4.24-os2-20141006.zip |
|
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.... |
|
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 |
|
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... |
|
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. |
|
OK... thanks. I'll switch over to this new one. The other one has worked well as a client - only about 24 hours though... |
|
Hate to say it, but I just got the 'libevent: select: Bad address' error :-( |
|
to be honest, I wasn't confident.... |
|
I added tor 0.2.6.10 to my site today, probably won't fix this issue though... |
|
Thanks Paul! This version seems to work with the same caveats as before, although I have not got a 'Bad Address' error yet... |
|
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. |
|
Thanks Paul (and Dmitriy)! I'll let you know what I see.... |
|
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) |
|
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. |
|
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 |
|
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.... |
|
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.... |
|
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 |
|
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.... |
|
Might need a rebuild against latest libcx.... htp://smedley.id.au/tmp/tor-0.2.8.7-os2-20160923.zip |
|
Thanks again... no change though, still get the warning and error listed above. |
|
ok - will have to report it to Dmitry |
|
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. |
|
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. |
|
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 |
|
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... |
|
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.... |
|
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... |
|
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) |
|
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... |
|
Hi Paul, Tor has started giving warnings about being out of date and need to update to the latest version. Any chance you could wip up a new build? |
|
hey Dave, will try look at it - I thought I had subscribed to tor-announce so that I would know about new builds... seems that didn't work :( |
|
http://smedley.id.au/tmp/tor-0.3.0.10-os2-20170811.zip |
|
dec 29 19:00:38.289 [Meddelande] Bootstrapped 100%: Done dec 29 19:34:31.711 [Varning] Warning from libevent: select: Bad address dec 29 19:34:31.711 [Fel] libevent call with select failed: Bad address [14] dec 29 20:04:11.305 [Meddelande] Tor 0.3.0.10 (git-c33db290a9d8d0f9) running on OS/2 with Libevent 2.0.21-stable, OpenSSL 1.0.2k and Zlib 1.2.5. |
|
There is a new build, probably doesn't help this issue, http://smedley.id.au/tmp/tor-0.3.2.8-rc-os2-20171223.zip |
|
Thank you. Will try it. It hopefully stay up longer. :-) |
|
dec 30 09:06:27.875 [Meddelande] Bootstrapped 100%: Done dec 30 09:28:23.119 [Varning] Warning from libevent: select: Bad address dec 30 09:28:23.119 [Fel] libevent call with select failed: Bad address [14] dec 30 09:28:37.207 [Meddelande] Tor 0.3.2.8-rc (git-63b84335dc590499) running on OS/2 with Libevent 2.0.21-stable, OpenSSL 1.0.2k, Zlib 1.2.5, Liblzma 5.0.3, and Libzstd N/A. |
|
Please try with http://smedley.id.au/tmp/tor-0.3.2.8-rc-os2-20171231.zip I added code to ignore an EBADF in the event loop from within tor. Hopefully this will fix the issue for good. It's a hack, but if it works :) |
|
Updated to latest tor release - http://smedley.id.au/tmp/tor-0.3.2.10-os2-20180304.zip |
|
Dave, any update? Is this safe to close with the latest build? |
|
Yes... haven't had a single libevent failure in either of the last 2 builds... thanks! |
|
Fixed in latest builds |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-04-12 20:23 | David McKenna | New Issue | |
2014-04-21 22:34 | psmedley | Note Added: 0002721 | |
2014-04-21 22:34 | psmedley | Assigned To | => psmedley |
2014-04-21 22:34 | psmedley | Status | new => feedback |
2014-04-22 22:06 | David McKenna | Note Added: 0002724 | |
2014-04-22 22:06 | David McKenna | Status | feedback => assigned |
2014-04-27 13:59 | David McKenna | Note Added: 0002725 | |
2014-05-02 22:16 | David McKenna | Note Added: 0002726 | |
2014-05-04 16:07 | David McKenna | Note Added: 0002727 | |
2014-05-05 10:51 | David McKenna | Note Added: 0002728 | |
2014-05-07 09:54 | psmedley | Note Added: 0002729 | |
2014-05-07 22:41 | David McKenna | File Added: tor-log.txt | |
2014-05-07 22:43 | David McKenna | Note Added: 0002730 | |
2014-05-08 11:57 | gianfli | Note Added: 0002731 | |
2014-05-08 12:02 | gianfli | Note Edited: 0002731 | |
2014-05-08 21:57 | psmedley | Note Added: 0002732 | |
2014-05-09 19:41 | gianfli | Note Added: 0002734 | |
2014-05-11 15:31 | gianfli | Note Added: 0002737 | |
2014-06-24 23:50 | David McKenna | Note Added: 0002765 | |
2014-06-24 23:51 | David McKenna | Note Edited: 0002765 | |
2014-06-25 00:27 | David McKenna | Note Added: 0002766 | |
2014-06-25 02:28 | psmedley | Note Added: 0002767 | |
2014-06-26 09:25 | psmedley | Note Added: 0002771 | |
2014-06-26 21:27 | David McKenna | Note Added: 0002772 | |
2014-06-28 23:34 | David McKenna | Note Added: 0002775 | |
2014-06-30 23:20 | David McKenna | Note Added: 0002779 | |
2014-07-14 22:33 | David McKenna | Note Added: 0002781 | |
2014-08-15 01:02 | David McKenna | Note Added: 0002816 | |
2014-08-15 09:30 | psmedley | Note Added: 0002817 | |
2014-08-16 14:43 | David McKenna | Note Added: 0002822 | |
2014-08-16 14:43 | David McKenna | File Added: bridge-0.2.23-debug.log | |
2014-08-17 04:06 | David McKenna | Note Added: 0002823 | |
2014-10-05 20:53 | psmedley | Note Added: 0002851 | |
2014-10-10 11:35 | David McKenna | Note Added: 0002864 | |
2014-11-08 08:22 | psmedley | Note Added: 0002905 | |
2014-11-09 01:01 | David McKenna | Note Added: 0002907 | |
2014-11-09 04:29 | psmedley | Note Added: 0002908 | |
2014-11-09 15:30 | David McKenna | Note Added: 0002910 | |
2014-11-10 12:22 | David McKenna | Note Added: 0002912 | |
2014-11-11 08:35 | psmedley | Note Added: 0002913 | |
2015-08-10 00:47 | psmedley | Note Added: 0003046 | |
2015-08-10 21:04 | David McKenna | Note Added: 0003048 | |
2016-01-27 08:36 | psmedley | Note Added: 0003105 | |
2016-01-27 12:09 | David McKenna | Note Added: 0003106 | |
2016-01-28 22:06 | David McKenna | Note Added: 0003107 | |
2016-01-31 20:43 | David McKenna | Note Added: 0003108 | |
2016-09-12 09:56 | psmedley | Note Added: 0003118 | |
2016-09-12 09:59 | psmedley | Note Edited: 0003118 | |
2016-09-17 18:40 | David McKenna | Note Added: 0003119 | |
2016-09-21 09:53 | psmedley | Note Added: 0003120 | |
2016-09-21 20:31 | David McKenna | Note Added: 0003121 | |
2016-09-23 00:13 | David McKenna | Note Added: 0003122 | |
2016-09-23 09:30 | psmedley | Note Added: 0003123 | |
2016-09-23 09:59 | psmedley | Note Edited: 0003123 | |
2016-09-23 10:26 | David McKenna | Note Added: 0003124 | |
2016-09-23 21:50 | psmedley | Note Added: 0003125 | |
2016-09-24 15:23 | David McKenna | Note Added: 0003126 | |
2016-09-24 17:22 | David McKenna | Note Added: 0003127 | |
2016-10-01 03:54 | psmedley | Note Added: 0003128 | |
2016-10-02 16:18 | David McKenna | Note Added: 0003129 | |
2016-10-04 20:30 | David McKenna | Note Added: 0003130 | |
2016-11-23 22:18 | David McKenna | Note Added: 0003131 | |
2016-11-24 09:01 | psmedley | Note Added: 0003132 | |
2016-11-24 15:31 | David McKenna | Note Added: 0003133 | |
2017-08-09 10:45 | David McKenna | Note Added: 0003145 | |
2017-08-10 09:25 | psmedley | Note Added: 0003146 | |
2017-08-11 08:52 | psmedley | Note Added: 0003147 | |
2017-12-29 19:04 | jep | Note Added: 0003162 | |
2017-12-29 20:07 | psmedley | Note Added: 0003163 | |
2017-12-29 23:32 | jep | Note Added: 0003164 | |
2017-12-30 08:30 | jep | Note Added: 0003165 | |
2017-12-31 07:32 | psmedley | Note Added: 0003166 | |
2018-03-03 20:43 | psmedley | Note Added: 0003170 | |
2018-04-22 09:31 | psmedley | Note Added: 0003176 | |
2018-04-22 12:37 | David McKenna | Note Added: 0003178 | |
2018-04-23 09:27 | psmedley | Status | assigned => resolved |
2018-04-23 09:27 | psmedley | Resolution | open => fixed |
2018-04-23 09:27 | psmedley | Note Added: 0003179 | |
2020-08-24 03:07 | psmedley | Status | resolved => closed |