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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
INVALID
People
(Reporter: mihneadb, Unassigned)
Details
Attachments
(1 file)
582 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•11 years ago
|
Assignee: nobody → mihneadb
Reporter | ||
Comment 1•11 years ago
|
||
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)
Comment 2•11 years ago
|
||
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)
Reporter | ||
Comment 3•11 years ago
|
||
(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
Comment 4•11 years ago
|
||
(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.
Reporter | ||
Comment 5•11 years ago
|
||
(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!
Reporter | ||
Updated•11 years ago
|
Assignee: mihneadb → nobody
Comment 6•11 years ago
|
||
Ok, I think I have a plan for fixing this. Testing now to see whether it will work.
Updated•11 years ago
|
Assignee: nobody → dpreston
Comment 7•11 years ago
|
||
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.
Reporter | ||
Comment 8•11 years ago
|
||
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.
Comment 9•11 years ago
|
||
Here's a bugfix for a typo which was preventing access to the localPort attribute.
Updated•10 years ago
|
Assignee: dpreston → nobody
Comment 10•6 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
Comment 11•5 months ago
|
||
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.
Description
•