Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1111437 > unrolled thread

Bug#1016357: Fails tests with insufficient network connectivity

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1016357: Fails tests with insufficient network connectivity Sven Mueller <sven.mueller72@gmail.com> - 2022-07-30 00:20 +0200
    Bug#1016357: Fails tests with insufficient network connectivity Nilesh Patra <nilesh@debian.org> - 2022-08-01 15:20 +0200
      Bug#1016357: Fails tests with insufficient network connectivity Shengjing Zhu <zhsj@debian.org> - 2022-08-01 17:00 +0200
        Bug#1016357: Fails tests with insufficient network connectivity Nilesh Patra <nilesh@debian.org> - 2022-08-01 17:10 +0200
          Bug#1016357: Fails tests with insufficient network connectivity Shengjing Zhu <zhsj@debian.org> - 2022-08-01 17:20 +0200
            Bug#1016357: Fails tests with insufficient network connectivity Nilesh Patra <nilesh@debian.org> - 2022-08-01 18:00 +0200
              Bug#1016357: Fails tests with insufficient network connectivity Shengjing Zhu <zhsj@debian.org> - 2022-08-01 18:00 +0200

#1111437 — Bug#1016357: Fails tests with insufficient network connectivity

Package: golang-github-pion-turn.v2
Version: 2.0.8-2
Severity: Serious

The package fails tests (see log of failing test below) when run on a
machine with limited network (in this case: Can only reach the
relevant APT repository server). This is a policy violation, which
says that package tests must only access local resources services that
were also spun up by the test. This tests tries to reach
stun1.l.google.com though. And fails with a nil pointer dereference...

=== RUN TestClientWithSTUN/SendBindingRequest
client_test.go:58:
Error Trace: client_test.go:58
Error: Received unexpected error:
all retransmissions failed for T/+GXOMeJz4c8ifu
Test: TestClientWithSTUN/SendBindingRequest
Messages: should succeed
--- FAIL: TestClientWithSTUN (7.81s)
--- FAIL: TestClientWithSTUN/SendBindingRequest (7.81s)
panic: runtime error: invalid memory address or nil pointer
dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x5cf212]

goroutine 7 [running]:
testing.tRunner.func1.2({0x5f8d40, 0x7b8d00})
/usr/lib/go-1.18/src/testing/testing.go:1389 +0x24e
testing.tRunner.func1()
/usr/lib/go-1.18/src/testing/testing.go:1392 +0x39f
panic({0x5f8d40, 0x7b8d00})
/usr/lib/go-1.18/src/runtime/panic.go:838 +0x207
github.com/pion/turn/v2.TestClientWithSTUN.func1(0x0?)
/<<PKGBUILDDIR>>/_build/src/github.com/pion/turn/v2/client_test.go:59 +0x152
testing.tRunner(0xc000109520, 0xc00002e2e0)
/usr/lib/go-1.18/src/testing/testing.go:1439 +0x102
created by testing.(*T).Run
/usr/lib/go-1.18/src/testing/testing.go:1486 +0x35f
FAIL github.com/pion/turn/v2 7.817s
? github.com/pion/turn/v2/examples/lt-cred-generator [no test files]
? github.com/pion/turn/v2/examples/turn-client/tcp [no test files]
? github.com/pion/turn/v2/examples/turn-client/udp [no test files]
? github.com/pion/turn/v2/examples/turn-server/add-software-attribute
[no test files]
? github.com/pion/turn/v2/examples/turn-server/log [no test files]
? github.com/pion/turn/v2/examples/turn-server/lt-cred [no test files]
? github.com/pion/turn/v2/examples/turn-server/port-range [no test files]
? github.com/pion/turn/v2/examples/turn-server/simple [no test files]
? github.com/pion/turn/v2/examples/turn-server/tcp [no test files]
? github.com/pion/turn/v2/examples/turn-server/tls [no test files]

Code in question: https://github.com/pion/turn/blob/master/client_test.go#L47

Cheers,
Sven

[toc] | [next] | [standalone]

#1111666

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 normal

On Fri, 29 Jul 2022 15:11:10 -0700 Sven Mueller <sven.mueller72@gmail.com> wrote:
> Package: golang-github-pion-turn.v2
> Version: 2.0.8-2
> Severity: Serious
> 
> The package fails tests (see log of failing test below) when run on a
> machine with limited network (in this case: Can only reach the
> relevant APT repository server). This is a policy violation, which
> says that package tests must only access local resources services that
> were also spun up by the test. This tests tries to reach
> stun1.l.google.com though. And fails with a nil pointer dereference...

I am not aware of any such policy -- can you please point me to it?
I've seen several packages in debian that access external URLs, and have
never seen them as any sort of policy violation, no such bugs either.

-- 
Best,
Nilesh

[toc] | [prev] | [next] | [standalone]

#1111670

On Mon, Aug 1, 2022 at 9:12 PM Nilesh Patra <nilesh@debian.org> wrote:
>
> Control: severity -1 normal
>
> On Fri, 29 Jul 2022 15:11:10 -0700 Sven Mueller <sven.mueller72@gmail.com> wrote:
> > Package: golang-github-pion-turn.v2
> > Version: 2.0.8-2
> > Severity: Serious
> >
> > The package fails tests (see log of failing test below) when run on a
> > machine with limited network (in this case: Can only reach the
> > relevant APT repository server). This is a policy violation, which
> > says that package tests must only access local resources services that
> > were also spun up by the test. This tests tries to reach
> > stun1.l.google.com though. And fails with a nil pointer dereference...
>
> I am not aware of any such policy -- can you please point me to it?

Debian policy 4.9:

For packages in the main archive, required targets must not attempt
network access, except, via the loopback interface, to services on the
build host that have been started by the build.

> I've seen several packages in debian that access external URLs, and have
> never seen them as any sort of policy violation, no such bugs either.
>

Please open bugs when you see that.

-- 
Shengjing Zhu

[toc] | [prev] | [next] | [standalone]

#1111672

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote:
> > > The package fails tests (see log of failing test below) when run on a
> > > machine with limited network (in this case: Can only reach the
> > > relevant APT repository server). This is a policy violation, which
> > > says that package tests must only access local resources services that
> > > were also spun up by the test. This tests tries to reach
> > > stun1.l.google.com though. And fails with a nil pointer dereference...
> >
> > I am not aware of any such policy -- can you please point me to it?
> 
> Debian policy 4.9:
> 
> For packages in the main archive, required targets must not attempt
> network access, except, via the loopback interface, to services on the
> build host that have been started by the build.

Thanks for the link. I was under the impression that network access is already
forbidden in the buildd environment, and package would not build if it tries
to do so -- not sure when that changed?

Also I presume that this policy is only for build, and not autopkgtests?

> > I've seen several packages in debian that access external URLs, and have
> > never seen them as any sort of policy violation, no such bugs either.
> >
> 
> Please open bugs when you see that.

There are a couple of python packages that I can think of doing so. Will open.

-- 
Best,
Nilesh

[toc] | [prev] | [next] | [standalone]

#1111673

On Mon, Aug 1, 2022 at 11:05 PM Nilesh Patra <nilesh@debian.org> wrote:
>
> On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote:
> > > > The package fails tests (see log of failing test below) when run on a
> > > > machine with limited network (in this case: Can only reach the
> > > > relevant APT repository server). This is a policy violation, which
> > > > says that package tests must only access local resources services that
> > > > were also spun up by the test. This tests tries to reach
> > > > stun1.l.google.com though. And fails with a nil pointer dereference...
> > >
> > > I am not aware of any such policy -- can you please point me to it?
> >
> > Debian policy 4.9:
> >
> > For packages in the main archive, required targets must not attempt
> > network access, except, via the loopback interface, to services on the
> > build host that have been started by the build.
>
> Thanks for the link. I was under the impression that network access is already
> forbidden in the buildd environment, and package would not build if it tries
> to do so -- not sure when that changed?

Because schroot doesn't implement network isolation.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802849

>
> Also I presume that this policy is only for build, and not autopkgtests?

Yes.

-- 
Shengjing Zhu

[toc] | [prev] | [next] | [standalone]

#1111677

[Multipart message — attachments visible in raw view] — view raw

On 8/1/22 8:38 PM, Shengjing Zhu wrote:
> On Mon, Aug 1, 2022 at 11:05 PM Nilesh Patra <nilesh@debian.org> wrote:
>>
>> On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote:
>>>>> The package fails tests (see log of failing test below) when run on a
>>>>> machine with limited network (in this case: Can only reach the
>>>>> relevant APT repository server). This is a policy violation, which
>>>>> says that package tests must only access local resources services that
>>>>> were also spun up by the test. This tests tries to reach
>>>>> stun1.l.google.com though. And fails with a nil pointer dereference...
>>>>
>>>> I am not aware of any such policy -- can you please point me to it?
>>>
>>> Debian policy 4.9:
>>>
>>> For packages in the main archive, required targets must not attempt
>>> network access, except, via the loopback interface, to services on the
>>> build host that have been started by the build.
>>
>> Thanks for the link. I was under the impression that network access is already
>> forbidden in the buildd environment, and package would not build if it tries
>> to do so -- not sure when that changed?
> 
> Because schroot doesn't implement network isolation.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802849

I am aware that this does not work locally because of the bug.
But one quick question - I was talking about the buildd (buildd.debian.org) machines
here. In the wiki, it says there is 'no network' in the machines[1]. However when I see the
setup using schroot[2]. Is it the same bug affecting it or do I miss something (since the
package was building fine earlier anyway)

[1]: https://wiki.debian.org/buildd#buildd_Differences
[2]: https://wiki.debian.org/BuilddSetup

-- 
Best,
Nilesh

[toc] | [prev] | [next] | [standalone]

#1111678

On Mon, Aug 1, 2022 at 11:50 PM Nilesh Patra <nilesh@debian.org> wrote:
>
> On 8/1/22 8:38 PM, Shengjing Zhu wrote:
> > On Mon, Aug 1, 2022 at 11:05 PM Nilesh Patra <nilesh@debian.org> wrote:
> >>
> >> On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote:
> >>>>> The package fails tests (see log of failing test below) when run on a
> >>>>> machine with limited network (in this case: Can only reach the
> >>>>> relevant APT repository server). This is a policy violation, which
> >>>>> says that package tests must only access local resources services that
> >>>>> were also spun up by the test. This tests tries to reach
> >>>>> stun1.l.google.com though. And fails with a nil pointer dereference...
> >>>>
> >>>> I am not aware of any such policy -- can you please point me to it?
> >>>
> >>> Debian policy 4.9:
> >>>
> >>> For packages in the main archive, required targets must not attempt
> >>> network access, except, via the loopback interface, to services on the
> >>> build host that have been started by the build.
> >>
> >> Thanks for the link. I was under the impression that network access is already
> >> forbidden in the buildd environment, and package would not build if it tries
> >> to do so -- not sure when that changed?
> >
> > Because schroot doesn't implement network isolation.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802849
>
> I am aware that this does not work locally because of the bug.
> But one quick question - I was talking about the buildd (buildd.debian.org) machines
> here. In the wiki, it says there is 'no network' in the machines[1]. However when I see the
> setup using schroot[2]. Is it the same bug affecting it or do I miss something (since the
> package was building fine earlier anyway)
>
> [1]: https://wiki.debian.org/buildd#buildd_Differences
> [2]: https://wiki.debian.org/BuilddSetup

Wiki is not always up to date. If you want the details, you'd better
ask buildd admins, and I'm not.

-- 
Shengjing Zhu

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web