Closed Bug 903830 Opened 11 years ago Closed 5 months ago

dom/network/tests/unit/test_tcpserversocket.js uses a hardcoded port

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: mihneadb, Unassigned)

Details

Attachments

(1 file)

This causes (intermittent) trouble when running the xpcshell tests in parallel. [self reminder] Must remove the run-sequentially annotation introduced in bug 898658 when this gets fixed.
Assignee: nobody → mihneadb
Blocks: 887064
Removing this as a dep because I'm having a bit of trouble with the interface. Will just mark the test to run-sequentially for now in bug 887054. I see in the .idl file that the port parameter is an *unsigned* and that's not good since I have to pass in -1 to get a dynamic port (as the docstring actually suggests). Also, I tried accessing the .port attribute (it's in the .idl as well) and the test just hangs. Could use some help on this! :) Thanks
No longer blocks: 887064
Flags: needinfo?(dpreston)
Isn't port 0 the port to use to get a dynamic port, not -1? Can you point me to the docstring you are talking about? Using port 0 and then accessing the .port attribute should be the correct way to get this to run in parallel. I will put an entry on my todo list to look into why accessing the .port attribute hangs.
Flags: needinfo?(dpreston)
(In reply to Donovan Preston from comment #2) > Isn't port 0 the port to use to get a dynamic port, not -1? Can you point me > to the docstring you are talking about? > > Using port 0 and then accessing the .port attribute should be the correct > way to get this to run in parallel. I will put an entry on my todo list to > look into why accessing the .port attribute hangs. 0 is in BSD/kernel land, yes. However, [1] says -1. [1] http://dxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMTCPSocket.idl#l60
(In reply to Mihnea Dobrescu-Balaur (:mihneadb) from comment #3) > 0 is in BSD/kernel land, yes. However, [1] says -1. > > [1] > http://dxr.mozilla.org/mozilla-central/source/dom/network/interfaces/ > nsIDOMTCPSocket.idl#l60 Hmm, you're right. I'm not sure I like that, I think I would prefer it to be 0. But that's not really important, the important thing is to figure out why passing -1 and then accessing .port hangs. I'll try to take a look tomorrow.
(In reply to Donovan Preston from comment #4) > (In reply to Mihnea Dobrescu-Balaur (:mihneadb) from comment #3) > > 0 is in BSD/kernel land, yes. However, [1] says -1. > > > > [1] > > http://dxr.mozilla.org/mozilla-central/source/dom/network/interfaces/ > > nsIDOMTCPSocket.idl#l60 > > Hmm, you're right. I'm not sure I like that, I think I would prefer it to be > 0. But that's not really important, the important thing is to figure out why > passing -1 and then accessing .port hangs. I'll try to take a look tomorrow. That's great, thanks!
Assignee: mihneadb → nobody
Ok, I think I have a plan for fixing this. Testing now to see whether it will work.
Assignee: nobody → dpreston
Ok, so first of all, the docs are wrong. You actually pass 0 to have the OS choose a free port, and it actually works right now. However, there is another bug, which is that it is not possible to know the port that was chosen when in a child process. I believe the port can't be discovered by the child process synchronously, either, so there will have to be a new "onlistening" event or something like that which will indicate the port is now known to the child process.
If the child process shares code with the parent you can inject it from there. If it is too complicated you can just keep it as is (run-sequentially) and all will be fine.
Here's a bugfix for a typo which was preventing access to the localPort attribute.
Assignee: dpreston → nobody
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3

The referenced files in the previous comments such as nsIDOMTCPSocket.idl or TCPServerSocket.js are no longer in the codebase.

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: