| # | User | Message | Date |
| 184 | Graham | I used to see this error on Cerebrus if I left it running long enough | 5-Aug 9:56 |
| 183 | Gabriele | i'll see if i can patch send on devbase so that it always closes the port. | 5-Aug 9:22 |
| 182 | Gabriele | this basically mean that we cannot rely on the gc closing our ports. | 5-Aug 9:20 |
| 181 | Gabriele | it may be the same problem (you get an error while sending, the port is not closed, and it gets closed in the wrong order by the GC so you get the port none not open error). | 5-Aug 9:19 |
| 180 | WillArp | sorry if it is not related 8) I'm sending out newsletter to thousand of users and I had to patch the send function like this http://reboot.ch/rebol/sendmail.txt I did try as suggested on rebol3 world to recycle after each send but that did not work (always had port none error stuff), the patched version works no problem. Thank you! | 5-Aug 5:56 |
| 179 | Carl | I think we have to move the port closer out of GC, and put it somewhere else. | 31-Jul 22:50 |
| 178 | Carl | "does not expect" | 31-Jul 22:50 |
| 177 | Carl | The R2 kernel knows about GC critical secions, but... it does known expect re-entrant interpreter evaluation within those sections. | 31-Jul 22:49 |
| 176 | Gabriele | i'm going to get some sleep... will check here tomorrow morning. | 31-Jul 22:49 |
| 175 | Carl | This is a dangerous condition.... | 31-Jul 22:48 |
| 174 | Carl | I think it may be necessary to change when it gets done. | 31-Jul 22:48 |
| 173 | Gabriele | "the gc is being disabled" is something that should go in the debug log ;) | 31-Jul 22:45 |
| 172 | Carl | probably | 31-Jul 22:44 |
| 171 | Gabriele | in the second run? | 31-Jul 22:43 |
| 170 | Gabriele | recycle got disabled? | 31-Jul 22:43 |
| 169 | Carl | If I run it again.... >> test testing... 0:00:00.5 testing... 0:00:00.515 testing... 0:00:00.516 testing... 0:00:00.516 | 31-Jul 22:43 |
| 168 | Carl | testing... 0:00:00.625 testing... 0:00:10.922 testing... 0:00:31.703 | 31-Jul 22:42 |
| 167 | Carl | timing it here... | 31-Jul 22:42 |
| 166 | Gabriele | happening at the first run here.. | 31-Jul 22:40 |
| 165 | Gabriele | >> s: now/precise loop 100 [b: clear [] loop 10000 [append b open/direct test://localhost] print difference now/precise s recycle] 0:00:00.358162 ** Math Error: Attempt to divide by zero ** Near: 1 / 0 | 31-Jul 22:39 |
| 164 | Carl | Removing the recycle.... | 31-Jul 22:37 |
| 163 | Gabriele | if i try to run it again after the error, i have to kill the rebol process because it eats all my ram. | 31-Jul 22:37 |
| 162 | Carl | It looks to me like it will take an hour.... | 31-Jul 22:36 |
| 161 | Gabriele | here, it errors out within a second. | 31-Jul 22:36 |
| 160 | Carl | how many minutes does that loop take??? | 31-Jul 22:36 |
| 159 | Gabriele | rebol --debug or something? | 31-Jul 22:35 |
| 158 | Gabriele | hmm... maybe it needs to be a CLI option? | 31-Jul 22:35 |
| 157 | Carl | I can try larger loop... | 31-Jul 22:34 |
| 156 | Carl | Question is... when should that field be checked for a filename? | 31-Jul 22:34 |
| 155 | Gabriele | did you try to increase the loops? i was using 100 and 10000 because the error seems very random... but i get it always with those numbers. | 31-Jul 22:34 |
| 154 | Gabriele | it can be very helpful to have something like this. | 31-Jul 22:33 |
| 153 | Gabriele | i think it is, debugging ports is far from easy. | 31-Jul 22:33 |
| 152 | Carl | system/ports/debug: %debug-output.txt | 31-Jul 22:33 |
| 151 | Carl | Regarding port debug... is it worth adding to system/ports object a debug field? | 31-Jul 22:32 |
| 150 | Carl | never | 31-Jul 22:31 |
| 149 | Gabriele | you never get the error? | 31-Jul 22:30 |
| 148 | Carl | Runs ok, multiple times. | 31-Jul 22:29 |
| 147 | Carl | make root-protocol [
open: func [port] [port]
close: func [port] [1 / 0]
net-utils/net-install 'test self 666
] test: does [ loop 10 [ b: clear [] loop 10 [append b open/direct test://localhost] recycle ] print read %gc-port-debug.txt ] | 31-Jul 22:29 |
| 146 | Carl | yes, gc disabled | 31-Jul 22:25 |
| 145 | Carl | works. | 31-Jul 22:24 |
| 144 | Carl | trying it | 31-Jul 22:22 |
| 143 | Gabriele | rebol just fills up your memory (gc disabled?) | 31-Jul 22:20 |
| 142 | Gabriele | notice that something strange happens if you run the loop again *after* you get that error. | 31-Jul 22:20 |
| 141 | Gabriele | >> make root-protocol [open: func [port] [port] close: func [port] [1 / 0] net-utils/net-install 'test self 666] test protocol loaded >> loop 100 [b: clear [] loop 10000 [append b open/direct test://localhost] recycle] ** Math Error: Attempt to divide by zero ** Near: 1 / 0 | 31-Jul 22:19 |
| 140 | Gabriele | i just picked a random port id :) | 31-Jul 22:19 |
| 139 | Carl | self 666? | 31-Jul 22:18 |
| 138 | Gabriele | i've got it to max my memory, killed it just before it would crash my system... let me try again... | 31-Jul 22:18 |
| 137 | Carl | Ok, ready to test. | 31-Jul 22:17 |
| 136 | Carl | Because in R2, any function arg will keep the value alive. | 31-Jul 22:13 |
| 135 | Carl | You will need to put it in a small loop... and do it a few times. | 31-Jul 22:12 |
| 134 | Gabriele | but, i cannot reproduce it. | 31-Jul 22:11 |
| 133 | Gabriele | >> recycle ** Math Error: Attempt to divide by zero ** Near: 1 / 0 | 31-Jul 22:11 |
| 132 | Gabriele | i got the error once: | 31-Jul 22:11 |
| 131 | Gabriele | so the try is working in this case? | 31-Jul 22:07 |
| 130 | Gabriele | though... if i leave the port hanging and try a recycle, i don't get any error. | 31-Jul 22:07 |
| 129 | Gabriele | >> make root-protocol [open: func [port] [port] close: func [port] [1 / 0] net-utils/net-install 'test self 666] test protocol loaded >> p: open/direct test://localhost >> close p ** Math Error: Attempt to divide by zero ** Near: 1 / 0 | 31-Jul 22:07 |
| 128 | Gabriele | ok, let me see... | 31-Jul 22:02 |
| 127 | Carl | bbs | 31-Jul 21:56 |
| 126 | Carl | But I will not attempt to fix it unless I can test it. | 31-Jul 21:55 |
| 125 | Carl | The problem that I see here is that the "try" method used by the GC is not valid. | 31-Jul 21:55 |
| 124 | Carl | The test should be just to have an error during close on a port. | 31-Jul 21:54 |
| 123 | Carl | If you can write a small test... I will make a small fix to 2.7. | 31-Jul 21:54 |
| 122 | Carl | I think I found a bug. | 31-Jul 21:52 |
| 121 | Gabriele | so that it is rethrown | 31-Jul 21:47 |
| 120 | Gabriele | hmm, i don't know how things are on the C side, but maybe the error returned by try is getting evaluated in some way? | 31-Jul 21:47 |
| 119 | Gabriele | but, i would have not figured out that was happening during the gc trying to close the imap port | 31-Jul 21:46 |
| 118 | Carl | Here is a puzzle: the code that calls close from the GC has a TRY wrapper on it. | 31-Jul 21:46 |
| 117 | Carl | good | 31-Jul 21:45 |
| 116 | Gabriele | your blog is #1 | 31-Jul 21:45 |
| 115 | Carl | Is google.it up to date on it too? | 31-Jul 21:44 |
| 114 | Carl | Well, today if you google port none not open (at least in US) you will get, at the top, the explanation. | 31-Jul 21:44 |
| 113 | Gabriele | or you would have pointed me to it immediatly :) | 31-Jul 21:43 |
| 112 | Gabriele | port tcp://... not open, where: 'recycle, i think i would have got it. | 31-Jul 21:42 |
| 111 | Gabriele | and, with the change of reporting the actual port that is not open, the error becomes clear. | 31-Jul 21:42 |
| 110 | Gabriele | if i had got: port none not open, near: rejoin [...] where: 'recycle i would have had a hint. (though i guess i would have not understood the problem anyway... but at least we can blog about it and people can search for error during recycle) | 31-Jul 21:41 |
| 109 | Carl | Checking something... | 31-Jul 21:41 |
| 108 | Gabriele | could the GC intercept the error and change the where field to say something like 'recycle? | 31-Jul 21:40 |
| 107 | Carl | It is a problem to ignore error exceptions, because they can include any condition. | 31-Jul 21:40 |
| 106 | Gabriele | not that i know of, but imap:// could very well be based over imapcommands:// in principle. i don't think there are any yet though. | 31-Jul 21:39 |
| 105 | Carl | Well, I am not sure if what you are suggesting is possible. | 31-Jul 21:39 |
| 104 | Gabriele | i think i've learned my lesson now, and will keep an eye on this kind of problem in the future... but, what about others? :) | 31-Jul 21:39 |
| 103 | Carl | Are there any triple layer ports... that you know of? | 31-Jul 21:38 |
| 102 | Gabriele | i'm still concerned about there being other cases where there is an error, and the user is left puzzled as to what is really happening. | 31-Jul 21:38 |
| 101 | Gabriele | that would be better. | 31-Jul 21:37 |
| 100 | Carl | What if the port sweep has 2 phases? The first pass only closes ports that have subports. The second pass closes all remaining ports. | 31-Jul 21:37 |
| 99 | Carl | Here's an idea... | 31-Jul 21:36 |
| 98 | Gabriele | that is a possibility. | 31-Jul 21:29 |
| 97 | Gabriele | it is a problematic situation one should not get into, by not letting those port being collected (and that was my bug), but then maybe we should throw an error message that does not get people confused (that port not open with the weird Near: got me completely off track) | 31-Jul 21:29 |
| 96 | Carl | What if we provided some kind of flag to indicate that a port should not be directly GC'd? | 31-Jul 21:29 |
| 95 | Gabriele | and, like in this case, the port cannot actually shut down the communication correctly, because the tcp port has already been closed. | 31-Jul 21:28 |
| 94 | Gabriele | agreed, but the GC would be closing any other port anyway eventually. | 31-Jul 21:28 |
| 93 | Carl | What if... | 31-Jul 21:27 |
| 92 | Carl | The scheme might have other things it needs to do on the close, such as close a log file. | 31-Jul 21:27 |
| 91 | Gabriele | the reason there is no check, is that normally if the tcp fails, you want to get an error. | 31-Jul 21:27 |
| 90 | Carl | The problem is, I am not sure if there is any way to solve this in REBOL itself. For example... | 31-Jul 21:26 |
| 89 | Gabriele | i agree the check is a good idea. | 31-Jul 21:26 |
| 88 | Gabriele | so it still happens "inside" the gc | 31-Jul 21:26 |
| 87 | Carl | But, perhaps TCP1 should do a check before assuming that TCP2 is open. | 31-Jul 21:26 |
| 86 | Gabriele | yep, but the error happens when GC attempts to close TCP1 | 31-Jul 21:25 |
| 85 | Carl | TCP1 uses TCP2. Then GC closes TCP2 first. | 31-Jul 21:25 |
| 84 | Gabriele | there are two ports, imapcommands:// which is my low level imap handler, and the tcp:// subport it uses | 31-Jul 21:25 |
| 83 | Carl | No, I understand. | 31-Jul 21:25 |
| 82 | Gabriele | no, that's not what's happening. i'll be more clear. | 31-Jul 21:25 |
| 81 | Carl | Regarding GC on ports... the error does not come from the GC. It comes from the usage of the port after the GC closes it. | 31-Jul 21:23 |
| 80 | Gabriele | ah, well, i can describe how it works if you are interested :) | 31-Jul 21:23 |
| 79 | Carl | Also, I don't understand the comment above about blowdart. One would expect that the fastcgi process itself should be serving your web interface only, with messages sent to various sub-service handlers, such as the IMAP server. But, then, I'm not the architect of QTask (nor do I know anything about its design.) | 31-Jul 21:22 |
| 78 | Gabriele | otherwise... the GC needs to be able to know the correct order for closing ports. | 31-Jul 21:22 |
| 77 | Gabriele | well, if the port is going to be destroyed anyway... is it critical to report errors when closing it? | 31-Jul 21:22 |
| 76 | Carl | Perhaps it should be an option on the port. | 31-Jul 21:20 |
| 75 | Gabriele | is it difficult to make it so errors during the GC run are reported in a way that it is obvious what's going on? otherwise i'd really prefer to have them ignored. | 31-Jul 20:45 |
| 74 | Gabriele | so... there's basically all of qtask in that process. | 31-Jul 20:39 |
| 73 | Gabriele | i don't know if it's only in fastcgi, i'd need to come up with some kind of test outside of fastcgi, but it's not easy because blowdart is the API interface to Qtask | 31-Jul 20:39 |
| 72 | Carl | The internal error above is very serious... and we must be able to easily reproduce it to find the problem. Is it only in FastCGI? | 31-Jul 17:24 |
| 71 | Carl | It may be possible to make this debug an option that you can turn on and off. | 31-Jul 17:23 |
| 70 | Carl | I think another possible solution in this area would be to just ignore CLOSE if port is already closed. | 31-Jul 17:21 |
| 69 | Carl | During GC we simply build a list of ports that need to be closed, then we finish the GC and close the ports. The ports themselves will not b GC'd until the *next* GC recycle. | 31-Jul 17:20 |
| 68 | Carl | Also, it is done outside of the primary GC critical sections. | 31-Jul 17:19 |
| 67 | Carl | Yes, there is special protection on CLOSE when done from GC. | 31-Jul 17:19 |
| 66 | Carl | Ok... seems like good progress. | 31-Jul 17:19 |
| 65 | Gabriele | let me know if you also want to debug them. It is annoying but less frequent than the port issue. | 31-Jul 14:45 |
| 64 | Gabriele | [Thu Jul 31 16:40:22 2008] [warn] FastCGI: (dynamic) server "/home/giesse/Qtask/Mercurial/qtask/rootdocs/blowdart.fcgi" (pid 15182) terminated by calling exit with status '50'
[Thu Jul 31 16:40:30 2008] [warn] FastCGI: (dynamic) server "/home/giesse/Qtask/Mercurial/qtask/rootdocs/blowdart.fcgi" restarted (pid 15362)
REBOL Internal Error: Invalid series width 1 was 16 (type 39) Program terminated abnormally. This should never happen. Contact www.REBOL.com with details. [Thu Jul 31 16:40:46 2008] [warn] FastCGI: (dynamic) server "/home/giesse/Qtask/Mercurial/qtask/rootdocs/blowdart.fcgi" (pid 15258) terminated by calling exit with status '50' | 31-Jul 14:44 |
| 63 | Gabriele | btw, even though my main problem is now "fixed" (but see above), i'm still getting these: | 31-Jul 14:44 |
| 62 | Gabriele | so my conclusion is... 1) the gc should ignore errors, or report them in a special way so that we know what's really happening 2) it would be useful to have a debug version of rebol that prints to a file like this. i would not have guessed what was happening here. | 31-Jul 10:08 |
| 61 | Gabriele | the other typo was causing the port being closed when it wasn't supposed to (and because of the first typo, it was not closed correctly) | 31-Jul 10:06 |
| 60 | Gabriele | (maybe the gc should ignore errors when closing ports.) | 31-Jul 10:06 |
| 59 | Gabriele | one typo was preventing the port being closed, so it ended up being closed by the gc eventually, and in the wrong order (tcp first) | 31-Jul 10:05 |
| 58 | Gabriele | ok, I had TWO typos in my code that, together, created this problem. :) still testing to make sure it works now... | 31-Jul 10:05 |
| 57 | Gabriele | maybe I've found the bug this time... | 31-Jul 9:45 |
| 56 | Gabriele | indeed, the problem still happens after i fixed that. | 31-Jul 9:28 |
| 55 | Gabriele | (i wonder why it doesn't happen more often though if that is the case. it should find more than one port hanging.) | 31-Jul 9:28 |
| 54 | Gabriele | (I wonder if the same thing is happening on the actual server...) | 31-Jul 9:26 |
| 53 | Gabriele | ah, maybe I had a bug in the stress test script that i was using that caused those ports to be GCed. doing more testing... | 31-Jul 9:25 |
| 52 | Gabriele | now, to figure out why those ports are getting collected... | 31-Jul 9:04 |
| 51 | Gabriele | I guess rebol does not like getting an error during the GC run. that's why the process sometimes crashes. | 31-Jul 9:04 |
| 50 | Gabriele | i guess that since this is happening during a gc run, the Near is being set to the code that was running when the GC run happened, which explains what I am seeing. | 31-Jul 9:03 |
| 49 | Gabriele | so, what happens is, that the GC is closing the TCP port first, then the IMAP port, which relies on it. So, when the IMAP port gets closed, it tries to send the quit command to the imap server, and there is an error. | 31-Jul 9:03 |
| 48 | Gabriele | GC : marking ports... GC : unused port : #087e6a90, tcp://pop.tiscali.it:143 local:40115 GC : unused port : #08ff3f60, imapcommands://pop.tiscali.it:143 GC : sweeping ports... GC : forced close: #087e6a90, tcp://pop.tiscali.it:143 local:40115 PORT: closed port : #087e6a90, tcp://pop.tiscali.it:143 local:40115 GC : forced close: #08ff3f60, imapcommands://pop.tiscali.it:143 ERROR: port not open: #087e6a90, tcp://pop.tiscali.it:143 local:40115 PORT: closed port : #090bfe98, tcp://:0 local:12150 PORT: closed port : #08eccd10, fastcgi:// | 31-Jul 9:02 |
| 47 | Gabriele | trying the new build... | 31-Jul 8:55 |
| 46 | Gabriele | I did not edit it in any way. | 31-Jul 8:55 |
| 45 | Carl | http://www.rebol.com/article/0371.html | 30-Jul 23:54 |
| 44 | Carl | Added better error msg: >> close a: open tcp://hq.rebol.net:80 >> copy a ** Access Error: Port tcp://hq.rebol.net:80 not open ** Near: copy a | 30-Jul 23:19 |
| 43 | Carl | Now prints the target, path, and local-port id. | 30-Jul 22:54 |
| 42 | Carl | Updated the exe's to print more info. | 30-Jul 22:52 |
| 41 | Carl | Also, for every line like:
GC : forced close: #09080a28, imapcommands://pop.tiscali.it:143 There should be a "closed port" line for that same port following it. If not, then the port errored out during the close. | 30-Jul 22:38 |
| 40 | Carl | Gabriele, in the debug output above... did you edit that? It's not right. The #hex numbers do not agree. | 30-Jul 22:35 |
| 39 | Carl | The port dispatcher in R2 builds a fake function context in order to get to the scheme handler functions. | 30-Jul 22:27 |
| 38 | Carl | An exception, or the internal port dispatcher. | 30-Jul 22:26 |
| 37 | Carl | Two things could be causing NEAR and WHERE problems... | 30-Jul 22:26 |
| 36 | Carl | Even AltME used to do that.... but I do not remember how it was fixed. | 30-Jul 22:25 |
| 35 | Carl | yes, that is strange, but I've seen it many times. | 30-Jul 22:25 |
| 34 | Gabriele | also i wonder why Near: and Where: are what they are. there is no port code in Near and I have no confirm in my IMAP code IIRC (but maybe I'm calling it in some case, i need to recheck, this was many months ago :) | 30-Jul 22:24 |
| 33 | Carl | ok. (however, I will not be here Friday.) | 30-Jul 22:23 |
| 32 | Gabriele | i'm going to get some sleep now... will post my results here tomorrow. | 30-Jul 22:23 |
| 31 | Carl | yes, try that. | 30-Jul 22:23 |
| 30 | Gabriele | I will add some debugging output to my code so that we can verify whether the port is still referenced or not. | 30-Jul 22:22 |
| 29 | Gabriele | when that object is removed from that block, CLOSE is called on the port, so I don't think it has been removed at that point. | 30-Jul 22:22 |
| 28 | Carl | you're kidding right? that would be really bad. | 30-Jul 22:21 |
| 27 | Gabriele | FYI, the imap port is referenced by an object that is stored in a block, assigned to a global word. | 30-Jul 22:21 |
| 26 | Carl | unused port = unreferenced port, so scheduled for gc | 30-Jul 22:21 |
| 25 | Carl | yes, the imap port is gc'd | 30-Jul 22:19 |
| 24 | Carl | looking... | 30-Jul 22:19 |
| 23 | Carl | off phone | 30-Jul 22:18 |
| 22 | Gabriele | I will do more tests tomorrow. How do you think we should proceed from here? maybe we can add more output when the error happens? printing the port # and url so that we can confirm it is the imap one. | 30-Jul 22:16 |
| 21 | Gabriele | PORT: opened port : #090b4600, file://:0 PORT: closed port : #090b4600, file://:0 PORT: opened port : #0909c530, tcp://pop.tiscali.it:143 PORT: opened port : #08fe0ea8, imapcommands://pop.tiscali.it:143 GC : marking ports... GC : unused port : #09083638, tcp://pop.tiscali.it:143 GC : unused port : #09080a28, imapcommands://pop.tiscali.it:143 GC : sweeping ports... GC : forced close: #09083638, tcp://pop.tiscali.it:143 PORT: closed port : #09083638, tcp://pop.tiscali.it:143 GC : forced close: #09080a28, imapcommands://pop.tiscali.it:143 PORT: closed port : #091c19d8, tcp://:0 PORT: closed port : #08f99f40, fastcgi://:0 | 30-Jul 22:14 |
| 20 | Carl | still on phone | 30-Jul 22:13 |
| 19 | Gabriele | the Near: and the Where: of the error do *not* point to my imap code, though. | 30-Jul 22:11 |
| 18 | Gabriele | so the GC is closing the IMAP port? | 30-Jul 22:10 |
| 17 | Gabriele | PORT: opened port : #09083638, file://:0 PORT: closed port : #09083638, file://:0 GC : marking ports... GC : unused port : #08804de0, tcp://pop.tiscali.it:143 GC : unused port : #088049e0, imapcommands://pop.tiscali.it:143 GC : sweeping ports... GC : forced close: #08804de0, tcp://pop.tiscali.it:143 PORT: closed port : #08804de0, tcp://pop.tiscali.it:143 GC : forced close: #088049e0, imapcommands://pop.tiscali.it:143 PORT: closed port : #08563890, tcp://:0 PORT: closed port : #0908daa8, fastcgi://:0 | 30-Jul 22:10 |
| 16 | Gabriele | got the error, and the file says: | 30-Jul 22:10 |
| 15 | Gabriele | going to give it a quick try... | 30-Jul 22:01 |
| 14 | Carl | releases/tests/ | 30-Jul 22:00 |
| 13 | Carl | win32 and linux uploaded | 30-Jul 22:00 |
| 12 | Carl | ok | 30-Jul 21:30 |
| 11 | Gabriele | REBOL/Command 2.7.6.4.2 (14-Mar-2008) | 30-Jul 21:29 |
| 10 | Gabriele | Command | 30-Jul 21:29 |
| 9 | Carl | what system/product? | 30-Jul 21:28 |
| 8 | Carl | yes. | 30-Jul 21:28 |
| 7 | Gabriele | ok. i can only test linux with fastcgi. | 30-Jul 21:27 |
| 6 | Carl | Building for win32 first... then Linux. | 30-Jul 21:27 |
| 5 | Gabriele | do you have the build uploaded already? | 30-Jul 21:26 |
| 4 | Carl | Example session... looping 3 times with OPEN tcp://www.rebol.net... Output is written to gc-port-debug.txt: GC : marking ports... GC : sweeping ports... GC : done... PORT: opened port : #0135f150, event://:0 PORT: opened port : #0135fd50, system://:0 PORT: opened port : #01360d50, file://:0 PORT: closed port : #01360d50, file://:0 PORT: opened port : #01370eb0, file://:0 PORT: closed port : #01370eb0, file://:0 PORT: opened port : #013716b0, tcp://www.rebol.net:80 PORT: opened port : #01371ab0, tcp://www.rebol.net:80 PORT: opened port : #01371eb0, tcp://www.rebol.net:80 GC : marking ports... GC : unused port : #013716b0, tcp://www.rebol.net:80 GC : unused port : #01371ab0, tcp://www.rebol.net:80 GC : sweeping ports... GC : forced close: #013716b0, tcp://www.rebol.net:80 PORT: closed port : #013716b0, tcp://www.rebol.net:80 GC : forced close: #01371ab0, tcp://www.rebol.net:80 PORT: closed port : #01371ab0, tcp://www.rebol.net:80 GC : done... PORT: closed port : #01371eb0, tcp://www.rebol.net:80 PORT: closed port : #0135fd50, system://:0 PORT: closed port : #0135f150, event://:0 REBOL terminated | 30-Jul 21:23 |
| 3 | Carl | Shows ports opening, closing, and gc'ing. | 30-Jul 21:21 |
| 2 | Carl | Generated a build to help track down the "port none not open" bug. | 30-Jul 21:20 |
| 1 | Carl | For debugging ports. | 30-Jul 21:20 |