| # | User | Message | Date |
| 184 | Graham | I used to see this error on Cerebrus if I left it running long enough | 5-Aug-08 9:56 |
| 183 | Gabriele | i'll see if i can patch send on devbase so that it always closes the port. | 5-Aug-08 9:22 |
| 182 | Gabriele | this basically mean that we cannot rely on the gc closing our ports. | 5-Aug-08 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-08 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-08 5:56 |
| 179 | Carl | I think we have to move the port closer out of GC, and put it somewhere else. | 31-Jul-08 22:50 |
| 178 | Carl | "does not expect" | 31-Jul-08 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-08 22:49 |
| 176 | Gabriele | i'm going to get some sleep... will check here tomorrow morning. | 31-Jul-08 22:49 |
| 175 | Carl | This is a dangerous condition.... | 31-Jul-08 22:48 |
| 174 | Carl | I think it may be necessary to change when it gets done. | 31-Jul-08 22:48 |
| 173 | Gabriele | "the gc is being disabled" is something that should go in the debug log ;) | 31-Jul-08 22:45 |
| 172 | Carl | probably | 31-Jul-08 22:44 |
| 171 | Gabriele | in the second run? | 31-Jul-08 22:43 |
| 170 | Gabriele | recycle got disabled? | 31-Jul-08 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-08 22:43 |
| 168 | Carl | testing... 0:00:00.625 testing... 0:00:10.922 testing... 0:00:31.703 | 31-Jul-08 22:42 |
| 167 | Carl | timing it here... | 31-Jul-08 22:42 |
| 166 | Gabriele | happening at the first run here.. | 31-Jul-08 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-08 22:39 |
| 164 | Carl | Removing the recycle.... | 31-Jul-08 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-08 22:37 |
| 162 | Carl | It looks to me like it will take an hour.... | 31-Jul-08 22:36 |
| 161 | Gabriele | here, it errors out within a second. | 31-Jul-08 22:36 |
| 160 | Carl | how many minutes does that loop take??? | 31-Jul-08 22:36 |
| 159 | Gabriele | rebol --debug or something? | 31-Jul-08 22:35 |
| 158 | Gabriele | hmm... maybe it needs to be a CLI option? | 31-Jul-08 22:35 |
| 157 | Carl | I can try larger loop... | 31-Jul-08 22:34 |
| 156 | Carl | Question is... when should that field be checked for a filename? | 31-Jul-08 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-08 22:34 |
| 154 | Gabriele | it can be very helpful to have something like this. | 31-Jul-08 22:33 |
| 153 | Gabriele | i think it is, debugging ports is far from easy. | 31-Jul-08 22:33 |
| 152 | Carl | system/ports/debug: %debug-output.txt | 31-Jul-08 22:33 |
| 151 | Carl | Regarding port debug... is it worth adding to system/ports object a debug field? | 31-Jul-08 22:32 |
| 150 | Carl | never | 31-Jul-08 22:31 |
| 149 | Gabriele | you never get the error? | 31-Jul-08 22:30 |
| 148 | Carl | Runs ok, multiple times. | 31-Jul-08 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-08 22:29 |
| 146 | Carl | yes, gc disabled | 31-Jul-08 22:25 |
| 145 | Carl | works. | 31-Jul-08 22:24 |
| 144 | Carl | trying it | 31-Jul-08 22:22 |
| 143 | Gabriele | rebol just fills up your memory (gc disabled?) | 31-Jul-08 22:20 |
| 142 | Gabriele | notice that something strange happens if you run the loop again *after* you get that error. | 31-Jul-08 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-08 22:19 |
| 140 | Gabriele | i just picked a random port id :) | 31-Jul-08 22:19 |
| 139 | Carl | self 666? | 31-Jul-08 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-08 22:18 |
| 137 | Carl | Ok, ready to test. | 31-Jul-08 22:17 |
| 136 | Carl | Because in R2, any function arg will keep the value alive. | 31-Jul-08 22:13 |
| 135 | Carl | You will need to put it in a small loop... and do it a few times. | 31-Jul-08 22:12 |
| 134 | Gabriele | but, i cannot reproduce it. | 31-Jul-08 22:11 |
| 133 | Gabriele | >> recycle ** Math Error: Attempt to divide by zero ** Near: 1 / 0 | 31-Jul-08 22:11 |
| 132 | Gabriele | i got the error once: | 31-Jul-08 22:11 |
| 131 | Gabriele | so the try is working in this case? | 31-Jul-08 22:07 |
| 130 | Gabriele | though... if i leave the port hanging and try a recycle, i don't get any error. | 31-Jul-08 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-08 22:07 |
| 128 | Gabriele | ok, let me see... | 31-Jul-08 22:02 |
| 127 | Carl | bbs | 31-Jul-08 21:56 |
| 126 | Carl | But I will not attempt to fix it unless I can test it. | 31-Jul-08 21:55 |
| 125 | Carl | The problem that I see here is that the "try" method used by the GC is not valid. | 31-Jul-08 21:55 |
| 124 | Carl | The test should be just to have an error during close on a port. | 31-Jul-08 21:54 |
| 123 | Carl | If you can write a small test... I will make a small fix to 2.7. | 31-Jul-08 21:54 |
| 122 | Carl | I think I found a bug. | 31-Jul-08 21:52 |
| 121 | Gabriele | so that it is rethrown | 31-Jul-08 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-08 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-08 21:46 |
| 118 | Carl | Here is a puzzle: the code that calls close from the GC has a TRY wrapper on it. | 31-Jul-08 21:46 |
| 117 | Carl | good | 31-Jul-08 21:45 |
| 116 | Gabriele | your blog is #1 | 31-Jul-08 21:45 |
| 115 | Carl | Is google.it up to date on it too? | 31-Jul-08 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-08 21:44 |
| 113 | Gabriele | or you would have pointed me to it immediatly :) | 31-Jul-08 21:43 |
| 112 | Gabriele | port tcp://... not open, where: 'recycle, i think i would have got it. | 31-Jul-08 21:42 |
| 111 | Gabriele | and, with the change of reporting the actual port that is not open, the error becomes clear. | 31-Jul-08 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-08 21:41 |
| 109 | Carl | Checking something... | 31-Jul-08 21:41 |
| 108 | Gabriele | could the GC intercept the error and change the where field to say something like 'recycle? | 31-Jul-08 21:40 |
| 107 | Carl | It is a problem to ignore error exceptions, because they can include any condition. | 31-Jul-08 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-08 21:39 |
| 105 | Carl | Well, I am not sure if what you are suggesting is possible. | 31-Jul-08 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-08 21:39 |
| 103 | Carl | Are there any triple layer ports... that you know of? | 31-Jul-08 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-08 21:38 |
| 101 | Gabriele | that would be better. | 31-Jul-08 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-08 21:37 |
| 99 | Carl | Here's an idea... | 31-Jul-08 21:36 |
| 98 | Gabriele | that is a possibility. | 31-Jul-08 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-08 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-08 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-08 21:28 |
| 94 | Gabriele | agreed, but the GC would be closing any other port anyway eventually. | 31-Jul-08 21:28 |
| 93 | Carl | What if... | 31-Jul-08 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-08 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-08 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-08 21:26 |
| 89 | Gabriele | i agree the check is a good idea. | 31-Jul-08 21:26 |
| 88 | Gabriele | so it still happens "inside" the gc | 31-Jul-08 21:26 |
| 87 | Carl | But, perhaps TCP1 should do a check before assuming that TCP2 is open. | 31-Jul-08 21:26 |
| 86 | Gabriele | yep, but the error happens when GC attempts to close TCP1 | 31-Jul-08 21:25 |
| 85 | Carl | TCP1 uses TCP2. Then GC closes TCP2 first. | 31-Jul-08 21:25 |
| 84 | Gabriele | there are two ports, imapcommands:// which is my low level imap handler, and the tcp:// subport it uses | 31-Jul-08 21:25 |
| 83 | Carl | No, I understand. | 31-Jul-08 21:25 |
| 82 | Gabriele | no, that's not what's happening. i'll be more clear. | 31-Jul-08 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-08 21:23 |
| 80 | Gabriele | ah, well, i can describe how it works if you are interested :) | 31-Jul-08 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-08 21:22 |
| 78 | Gabriele | otherwise... the GC needs to be able to know the correct order for closing ports. | 31-Jul-08 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-08 21:22 |
| 76 | Carl | Perhaps it should be an option on the port. | 31-Jul-08 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-08 20:45 |
| 74 | Gabriele | so... there's basically all of qtask in that process. | 31-Jul-08 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-08 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-08 17:24 |
| 71 | Carl | It may be possible to make this debug an option that you can turn on and off. | 31-Jul-08 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-08 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-08 17:20 |
| 68 | Carl | Also, it is done outside of the primary GC critical sections. | 31-Jul-08 17:19 |
| 67 | Carl | Yes, there is special protection on CLOSE when done from GC. | 31-Jul-08 17:19 |
| 66 | Carl | Ok... seems like good progress. | 31-Jul-08 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-08 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-08 14:44 |
| 63 | Gabriele | btw, even though my main problem is now "fixed" (but see above), i'm still getting these: | 31-Jul-08 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-08 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-08 10:06 |
| 60 | Gabriele | (maybe the gc should ignore errors when closing ports.) | 31-Jul-08 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-08 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-08 10:05 |
| 57 | Gabriele | maybe I've found the bug this time... | 31-Jul-08 9:45 |
| 56 | Gabriele | indeed, the problem still happens after i fixed that. | 31-Jul-08 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-08 9:28 |
| 54 | Gabriele | (I wonder if the same thing is happening on the actual server...) | 31-Jul-08 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-08 9:25 |
| 52 | Gabriele | now, to figure out why those ports are getting collected... | 31-Jul-08 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-08 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-08 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-08 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-08 9:02 |
| 47 | Gabriele | trying the new build... | 31-Jul-08 8:55 |
| 46 | Gabriele | I did not edit it in any way. | 31-Jul-08 8:55 |
| 45 | Carl | http://www.rebol.com/article/0371.html | 30-Jul-08 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-08 23:19 |
| 43 | Carl | Now prints the target, path, and local-port id. | 30-Jul-08 22:54 |
| 42 | Carl | Updated the exe's to print more info. | 30-Jul-08 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-08 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-08 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-08 22:27 |
| 38 | Carl | An exception, or the internal port dispatcher. | 30-Jul-08 22:26 |
| 37 | Carl | Two things could be causing NEAR and WHERE problems... | 30-Jul-08 22:26 |
| 36 | Carl | Even AltME used to do that.... but I do not remember how it was fixed. | 30-Jul-08 22:25 |
| 35 | Carl | yes, that is strange, but I've seen it many times. | 30-Jul-08 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-08 22:24 |
| 33 | Carl | ok. (however, I will not be here Friday.) | 30-Jul-08 22:23 |
| 32 | Gabriele | i'm going to get some sleep now... will post my results here tomorrow. | 30-Jul-08 22:23 |
| 31 | Carl | yes, try that. | 30-Jul-08 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-08 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-08 22:22 |
| 28 | Carl | you're kidding right? that would be really bad. | 30-Jul-08 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-08 22:21 |
| 26 | Carl | unused port = unreferenced port, so scheduled for gc | 30-Jul-08 22:21 |
| 25 | Carl | yes, the imap port is gc'd | 30-Jul-08 22:19 |
| 24 | Carl | looking... | 30-Jul-08 22:19 |
| 23 | Carl | off phone | 30-Jul-08 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-08 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-08 22:14 |
| 20 | Carl | still on phone | 30-Jul-08 22:13 |
| 19 | Gabriele | the Near: and the Where: of the error do *not* point to my imap code, though. | 30-Jul-08 22:11 |
| 18 | Gabriele | so the GC is closing the IMAP port? | 30-Jul-08 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-08 22:10 |
| 16 | Gabriele | got the error, and the file says: | 30-Jul-08 22:10 |
| 15 | Gabriele | going to give it a quick try... | 30-Jul-08 22:01 |
| 14 | Carl | releases/tests/ | 30-Jul-08 22:00 |
| 13 | Carl | win32 and linux uploaded | 30-Jul-08 22:00 |
| 12 | Carl | ok | 30-Jul-08 21:30 |
| 11 | Gabriele | REBOL/Command 2.7.6.4.2 (14-Mar-2008) | 30-Jul-08 21:29 |
| 10 | Gabriele | Command | 30-Jul-08 21:29 |
| 9 | Carl | what system/product? | 30-Jul-08 21:28 |
| 8 | Carl | yes. | 30-Jul-08 21:28 |
| 7 | Gabriele | ok. i can only test linux with fastcgi. | 30-Jul-08 21:27 |
| 6 | Carl | Building for win32 first... then Linux. | 30-Jul-08 21:27 |
| 5 | Gabriele | do you have the build uploaded already? | 30-Jul-08 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-08 21:23 |
| 3 | Carl | Shows ports opening, closing, and gc'ing. | 30-Jul-08 21:21 |
| 2 | Carl | Generated a build to help track down the "port none not open" bug. | 30-Jul-08 21:20 |
| 1 | Carl | For debugging ports. | 30-Jul-08 21:20 |