Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue)
On Sun, Nov 21, 2021 at 10:46:30PM +0100, Peter wrote:
> ## this seems not have arrived on the list at first send ##
>
> > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d",
> > line 106: failed to copy type of 'inp': Conflicting type is already defined
>
> > That file ipfw.d appears to be new in 12.3, but I'm clueless what
> > the error means (and why it happens only to me).
>
>
> I figured out why - I have "device dtraceall" in my kernel. This is
> reproducible:
>
> > root@y12y:/ # dtrace -h
> > dtrace: -h requires one or more scripts or enabling options
> > root@y12y:/ # kldload dtraceall
> > root@y12y:/ # dtrace -h
> > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line
> > 106: failed to copy type of 'inp': Conflicting type is already defined
> > root@y12y:/ # kldunload dtraceall
> > root@y12y:/ # dtrace -h
> > dtrace: -h requires one or more scripts or enabling options
>
>
> But we do already have a bug (#254483) for this error.
>
> This bug was closed as duplicate to bug #258763, and the latter one
> was closed as solved with a fix as stated here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258763#c7
>
>
> But the fancy is:
>
> 1. that fix appears to have missed the releng/12.3 branch by three
> days, so it is not in the code. But also
>
> 2. if applied, (*surprize*) that fix does NOT help!
Hmm, that is indeed surprising. I'm able to reproduce the problem
locally.
> More than one thing is wrong here, and bug #254483 is *not* a
> duplicate to #258763.
>
> The failure does NOT come from code covered by Mark Johnstons fix.
>
> It comes from a neighboring section where Integers are compared, and
> it fails with a type conflict 8bit vs. 32bit.
>
>
> The problem must be within /usr/lib/dtrace/ipfw.d - and indeed
> it is (irrelevant parts stripped away):
>
> > typedef struct ipfw_match_info {
> >struct mbuf *m;
> > } ipfw_match_info_t;
> >
> > translator ipfw_match_info_t < struct ip_fw_args *p > {
> >m = p->m;
> > };
>
> This does not work. Within the 'struct mbuf' definition is a
> construct, that looks like this:
>
> >uint32_t m_type:8, /* type of data in this mbuf */
> > m_flags:24;/* flags; see below */
>
> And it seems that is somehow the cause for the integer size conflict
> (not implemented?)
How did you come to that conclusion?
> In the neighboring file /usr/lib/dtrace/mbuf.d this is done
> distinctively:
>
> > translator mbufinfo_t < struct mbuf *p > {
> >mbuf_addr = (uintptr_t)p;
> >m_data = p->m_data;
> >m_len = p->m_len;
> >m_type = p->m_type & 0xff00;
> >m_flags = p->m_type & 0x00ff;
> >};
>
> So probably we should just duplicate that approach for ipfw.
>
> Or, could that definition be directly included and called? Does dtrace
> allow one tranlation to call another?
> I can't answer that, have never been that deep in dtrace - but I
> really love the idea that we now get means to look into ipfw. Comes in
> handy and at the right time. :)
Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue)
On Mon, Nov 22, 2021 at 10:45:09AM -0500, Mark Johnston wrote:
> On Sun, Nov 21, 2021 at 10:46:30PM +0100, Peter wrote:
> > ## this seems not have arrived on the list at first send ##
> >
> > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d",
> > > line 106: failed to copy type of 'inp': Conflicting type is already
> > > defined
> >
> > > That file ipfw.d appears to be new in 12.3, but I'm clueless what
> > > the error means (and why it happens only to me).
> >
> >
> > I figured out why - I have "device dtraceall" in my kernel. This is
> > reproducible:
> >
> > > root@y12y:/ # dtrace -h
> > > dtrace: -h requires one or more scripts or enabling options
> > > root@y12y:/ # kldload dtraceall
> > > root@y12y:/ # dtrace -h
> > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line
> > > 106: failed to copy type of 'inp': Conflicting type is already defined
> > > root@y12y:/ # kldunload dtraceall
> > > root@y12y:/ # dtrace -h
> > > dtrace: -h requires one or more scripts or enabling options
> >
> >
> > But we do already have a bug (#254483) for this error.
> >
> > This bug was closed as duplicate to bug #258763, and the latter one
> > was closed as solved with a fix as stated here:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258763#c7
> >
> >
> > But the fancy is:
> >
> > 1. that fix appears to have missed the releng/12.3 branch by three
> > days, so it is not in the code. But also
> >
> > 2. if applied, (*surprize*) that fix does NOT help!
>
> Hmm, that is indeed surprising. I'm able to reproduce the problem
> locally.
>
> > More than one thing is wrong here, and bug #254483 is *not* a
> > duplicate to #258763.
> >
> > The failure does NOT come from code covered by Mark Johnstons fix.
> >
> > It comes from a neighboring section where Integers are compared, and
> > it fails with a type conflict 8bit vs. 32bit.
> >
> >
> > The problem must be within /usr/lib/dtrace/ipfw.d - and indeed
> > it is (irrelevant parts stripped away):
> >
> > > typedef struct ipfw_match_info {
> > >struct mbuf *m;
> > > } ipfw_match_info_t;
> > >
> > > translator ipfw_match_info_t < struct ip_fw_args *p > {
> > >m = p->m;
> > > };
> >
> > This does not work. Within the 'struct mbuf' definition is a
> > construct, that looks like this:
> >
> > >uint32_t m_type:8, /* type of data in this mbuf */
> > > m_flags:24;/* flags; see below */
> >
> > And it seems that is somehow the cause for the integer size conflict
> > (not implemented?)
>
> How did you come to that conclusion?
Indeed, the problem had to do with handling of bitfield types in libctf.
The problem you found is fixed by
https://cgit.freebsd.org/src/commit/?id=3cbb4cc200f8a0ad7ed08233425ea54524a21f1c
but that change was not merged to 12. I just merged it to stable/12 and
will try to get both libctf changes into 12.3, as both are required for
dtrace to work properly while ipfw.ko is loaded.
Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue)
On Mon, Nov 22, 2021 at 10:45:09AM -0500, Mark Johnston wrote:
! On Sun, Nov 21, 2021 at 10:46:30PM +0100, Peter wrote:
! > ## this seems not have arrived on the list at first send ##
! >
! > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d",
! > > line 106: failed to copy type of 'inp': Conflicting type is already
defined
! >
! > > That file ipfw.d appears to be new in 12.3, but I'm clueless what
! > > the error means (and why it happens only to me).
! >
! >
! > I figured out why - I have "device dtraceall" in my kernel. This is
! > reproducible:
! >
! > > root@y12y:/ # dtrace -h
! > > dtrace: -h requires one or more scripts or enabling options
! > > root@y12y:/ # kldload dtraceall
! > > root@y12y:/ # dtrace -h
! > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line
106: failed to copy type of 'inp': Conflicting type is already defined
! > > root@y12y:/ # kldunload dtraceall
! > > root@y12y:/ # dtrace -h
! > > dtrace: -h requires one or more scripts or enabling options
! >
! >
! > But we do already have a bug (#254483) for this error.
! >
! > This bug was closed as duplicate to bug #258763, and the latter one
! > was closed as solved with a fix as stated here:
! > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258763#c7
! >
! >
! > But the fancy is:
! >
! > 1. that fix appears to have missed the releng/12.3 branch by three
! > days, so it is not in the code. But also
! >
! > 2. if applied, (*surprize*) that fix does NOT help!
!
! Hmm, that is indeed surprising. I'm able to reproduce the problem
! locally.
!
! > More than one thing is wrong here, and bug #254483 is *not* a
! > duplicate to #258763.
! >
! > The failure does NOT come from code covered by Mark Johnstons fix.
! >
! > It comes from a neighboring section where Integers are compared, and
! > it fails with a type conflict 8bit vs. 32bit.
! >
! >
! > The problem must be within /usr/lib/dtrace/ipfw.d - and indeed
! > it is (irrelevant parts stripped away):
! >
! > > typedef struct ipfw_match_info {
! > >struct mbuf *m;
! > > } ipfw_match_info_t;
! > >
! > > translator ipfw_match_info_t < struct ip_fw_args *p > {
! > >m = p->m;
! > > };
! >
! > This does not work. Within the 'struct mbuf' definition is a
! > construct, that looks like this:
! >
! > >uint32_t m_type:8, /* type of data in this mbuf */
! > > m_flags:24;/* flags; see below */
! >
! > And it seems that is somehow the cause for the integer size conflict
! > (not implemented?)
!
! How did you come to that conclusion?
Well, that's my trade secret :)
| Indeed, the problem had to do with handling of bitfield types in libctf.
| The problem you found is fixed by
|
https://cgit.freebsd.org/src/commit/?id=3cbb4cc200f8a0ad7ed08233425ea54524a21f1c
| but that change was not merged to 12. I just merged it to stable/12 and
| will try to get both libctf changes into 12.3, as both are required for
| dtrace to work properly while ipfw.ko is loaded.
That would be great, but ... I gave that patch a quick try, and
doesn't yet seem to work, it is now a different error message:
> dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line
> 106: failed to copy type of 'inp': Invalid type identifier
Cheerio,
PMc
Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue)
On Mon, Nov 22, 2021 at 09:52:38PM +0100, Peter wrote:
> On Mon, Nov 22, 2021 at 10:45:09AM -0500, Mark Johnston wrote:
> ! On Sun, Nov 21, 2021 at 10:46:30PM +0100, Peter wrote:
> ! > ## this seems not have arrived on the list at first send ##
> ! >
> ! > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d",
> ! > > line 106: failed to copy type of 'inp': Conflicting type is already
> defined
> ! >
> ! > > That file ipfw.d appears to be new in 12.3, but I'm clueless what
> ! > > the error means (and why it happens only to me).
> ! >
> ! >
> ! > I figured out why - I have "device dtraceall" in my kernel. This is
> ! > reproducible:
> ! >
> ! > > root@y12y:/ # dtrace -h
> ! > > dtrace: -h requires one or more scripts or enabling options
> ! > > root@y12y:/ # kldload dtraceall
> ! > > root@y12y:/ # dtrace -h
> ! > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d",
> line 106: failed to copy type of 'inp': Conflicting type is already defined
> ! > > root@y12y:/ # kldunload dtraceall
> ! > > root@y12y:/ # dtrace -h
> ! > > dtrace: -h requires one or more scripts or enabling options
> ! >
> ! >
> ! > But we do already have a bug (#254483) for this error.
> ! >
> ! > This bug was closed as duplicate to bug #258763, and the latter one
> ! > was closed as solved with a fix as stated here:
> ! > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258763#c7
> ! >
> ! >
> ! > But the fancy is:
> ! >
> ! > 1. that fix appears to have missed the releng/12.3 branch by three
> ! > days, so it is not in the code. But also
> ! >
> ! > 2. if applied, (*surprize*) that fix does NOT help!
> !
> ! Hmm, that is indeed surprising. I'm able to reproduce the problem
> ! locally.
> !
> ! > More than one thing is wrong here, and bug #254483 is *not* a
> ! > duplicate to #258763.
> ! >
> ! > The failure does NOT come from code covered by Mark Johnstons fix.
> ! >
> ! > It comes from a neighboring section where Integers are compared, and
> ! > it fails with a type conflict 8bit vs. 32bit.
> ! >
> ! >
> ! > The problem must be within /usr/lib/dtrace/ipfw.d - and indeed
> ! > it is (irrelevant parts stripped away):
> ! >
> ! > > typedef struct ipfw_match_info {
> ! > >struct mbuf *m;
> ! > > } ipfw_match_info_t;
> ! > >
> ! > > translator ipfw_match_info_t < struct ip_fw_args *p > {
> ! > >m = p->m;
> ! > > };
> ! >
> ! > This does not work. Within the 'struct mbuf' definition is a
> ! > construct, that looks like this:
> ! >
> ! > >uint32_t m_type:8, /* type of data in this mbuf */
> ! > > m_flags:24;/* flags; see below */
> ! >
> ! > And it seems that is somehow the cause for the integer size conflict
> ! > (not implemented?)
> !
> ! How did you come to that conclusion?
>
> Well, that's my trade secret :)
>
> | Indeed, the problem had to do with handling of bitfield types in libctf.
> | The problem you found is fixed by
> |
> https://cgit.freebsd.org/src/commit/?id=3cbb4cc200f8a0ad7ed08233425ea54524a21f1c
> | but that change was not merged to 12. I just merged it to stable/12 and
> | will try to get both libctf changes into 12.3, as both are required for
> | dtrace to work properly while ipfw.ko is loaded.
>
> That would be great, but ... I gave that patch a quick try, and
> doesn't yet seem to work, it is now a different error message:
>
> > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line
> > 106: failed to copy type of 'inp': Invalid type identifier
Hmm. Just to be clear, this is with both libctf patches applied,
libctf.so reinstalled, and with a pristine ipfw.d? If so, I'm not able
to reproduce the problem.
Re: 12.3-RC1 fails to compile perl,tcl86 (ipfw dtrace issue)
On Mon, Nov 22, 2021 at 04:09:43PM -0500, Mark Johnston wrote:
! On Mon, Nov 22, 2021 at 09:52:38PM +0100, Peter wrote:
! > On Mon, Nov 22, 2021 at 10:45:09AM -0500, Mark Johnston wrote:
! > ! On Sun, Nov 21, 2021 at 10:46:30PM +0100, Peter wrote:
! > ! > ## this seems not have arrived on the list at first send ##
! > ! >
! > ! > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d",
! > ! > > line 106: failed to copy type of 'inp': Conflicting type is already
defined
! > ! >
! > ! > > That file ipfw.d appears to be new in 12.3, but I'm clueless what
! > ! > > the error means (and why it happens only to me).
! > ! >
! > ! >
! > ! > I figured out why - I have "device dtraceall" in my kernel. This is
! > ! > reproducible:
! > ! >
! > ! > > root@y12y:/ # dtrace -h
! > ! > > dtrace: -h requires one or more scripts or enabling options
! > ! > > root@y12y:/ # kldload dtraceall
! > ! > > root@y12y:/ # dtrace -h
! > ! > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d",
line 106: failed to copy type of 'inp': Conflicting type is already defined
! > ! > > root@y12y:/ # kldunload dtraceall
! > ! > > root@y12y:/ # dtrace -h
! > ! > > dtrace: -h requires one or more scripts or enabling options
! > ! >
! > ! >
! > ! > But we do already have a bug (#254483) for this error.
! > ! >
! > ! > This bug was closed as duplicate to bug #258763, and the latter one
! > ! > was closed as solved with a fix as stated here:
! > ! > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258763#c7
! > ! >
! > ! >
! > ! > But the fancy is:
! > ! >
! > ! > 1. that fix appears to have missed the releng/12.3 branch by three
! > ! > days, so it is not in the code. But also
! > ! >
! > ! > 2. if applied, (*surprize*) that fix does NOT help!
! > !
! > ! Hmm, that is indeed surprising. I'm able to reproduce the problem
! > ! locally.
! > !
! > ! > More than one thing is wrong here, and bug #254483 is *not* a
! > ! > duplicate to #258763.
! > ! >
! > ! > The failure does NOT come from code covered by Mark Johnstons fix.
! > ! >
! > ! > It comes from a neighboring section where Integers are compared, and
! > ! > it fails with a type conflict 8bit vs. 32bit.
! > ! >
! > ! >
! > ! > The problem must be within /usr/lib/dtrace/ipfw.d - and indeed
! > ! > it is (irrelevant parts stripped away):
! > ! >
! > ! > > typedef struct ipfw_match_info {
! > ! > >struct mbuf *m;
! > ! > > } ipfw_match_info_t;
! > ! > >
! > ! > > translator ipfw_match_info_t < struct ip_fw_args *p > {
! > ! > >m = p->m;
! > ! > > };
! > ! >
! > ! > This does not work. Within the 'struct mbuf' definition is a
! > ! > construct, that looks like this:
! > ! >
! > ! > >uint32_t m_type:8, /* type of data in this mbuf */
! > ! > > m_flags:24;/* flags; see below */
! > ! >
! > ! > And it seems that is somehow the cause for the integer size conflict
! > ! > (not implemented?)
! > !
! > ! How did you come to that conclusion?
! >
! > Well, that's my trade secret :)
! >
! > | Indeed, the problem had to do with handling of bitfield types in libctf.
! > | The problem you found is fixed by
! > |
https://cgit.freebsd.org/src/commit/?id=3cbb4cc200f8a0ad7ed08233425ea54524a21f1c
! > | but that change was not merged to 12. I just merged it to stable/12 and
! > | will try to get both libctf changes into 12.3, as both are required for
! > | dtrace to work properly while ipfw.ko is loaded.
! >
! > That would be great, but ... I gave that patch a quick try, and
! > doesn't yet seem to work, it is now a different error message:
! >
! > > dtrace: failed to establish error handler: "/usr/lib/dtrace/ipfw.d", line
106: failed to copy type of 'inp': Invalid type identifier
!
! Hmm. Just to be clear, this is with both libctf patches applied,
Ahh, My mistake, I had the other patch put away as no apparent effect
at first try. So now I know it has an effect. ;)
Very well, it does work now.
Cheerio,
PMc
