RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1547472 - [abrt] [faf] libteam: unknown function(): /usr/bin/teamd killed by 11
Summary: [abrt] [faf] libteam: unknown function(): /usr/bin/teamd killed by 11
Keywords:
Status: CLOSED DUPLICATE of bug 1563155
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libteam
Version: 7.5-Alt
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Xin Long
QA Contact: Network QE
URL: http://faf.lab.eng.brq.redhat.com/faf...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-21 12:07 UTC by Vladimir Benes
Modified: 2018-07-02 11:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-02 11:39:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Vladimir Benes 2018-02-21 12:07:58 UTC
This bug has been created based on an anonymous crash report requested by the package maintainer.

Report URL: http://faf.lab.eng.brq.redhat.com/faf/reports/bthash/ddd8b99e9e94d397a8b442e0285b0ac1be58e638/

not sure if the crash is clear from backtrace, but I can definitelly dig deeper to NM test suite to find reproducer.

Comment 2 Marcelo Ricardo Leitner 2018-02-23 13:58:40 UTC
I'm guessing this was an internal error on glibc (vsnprintf). Maybe it couldn't allocate enough memory.

Comment 3 Xin Long 2018-02-26 12:05:40 UTC
(gdb) select-frame 5
(gdb) p port->ifinfo
$1 = (struct team_ifinfo *) 0x0

static bool __team_port_str(struct team_port *port,
                            char **pbuf, size_t *pbufsiz)
{
        uint32_t ifindex = team_get_port_ifindex(port);
        struct team_ifinfo *ifinfo = team_get_port_ifinfo(port); <--- NULL

        return __buf_append(...
                            team_get_ifinfo_ifname(ifinfo), <--- crash

Introduced by:
commit 046fb6ba0aec8246075b18d787daec43201566fa
Author: Antti Tiainen <atiainen>
Date:   Mon Feb 6 15:41:05 2017 +0200

    libteam: resynchronize ifinfo after lost RTNLGRP_LINK notifications

team_port's ifinfo should not be null, but ifinfo's destroy is earlier than team_port, so we have to delay it, the fix could be something like:

 static void ifinfo_destroy(struct team_ifinfo *ifinfo)
 {
-       if (ifinfo->linked && ifinfo->port)
-               port_unlink(ifinfo->port);
        list_del(&ifinfo->list);
+       if (ifinfo->linked && ifinfo->port)
+               return;
        free(ifinfo);
 }

@@ -470,6 +470,9 @@ void ifinfo_unlink(struct team_ifinfo *ifinfo)
 {
        ifinfo->port = NULL;
        ifinfo->linked = false;
+
+       if (list_empty(&ifinfo->list))
+               free(ifinfo);
 }

after which, we can also do the similar thing for port and option's cleanup as the commit does for ifinfo, and remove them from elsewhere, it would be a nice improvement.
@@ -240,6 +240,13 @@ int check_call_change_handlers(struct team_handle *th,
                ifinfo_destroy_removed(th);
                ifinfo_clear_changed(th);
        }
+
+       if (call_type_mask & TEAM_PORT_CHANGE)
+               port_list_cleanup_last_state(th);
+
+       if (call_type_mask & TEAM_OPTION_CHANGE)
+               option_list_cleanup_last_state(th);
+
        th->change_handler.pending_type_mask &= ~call_type_mask;
        return err;
 }

Comment 4 Marcelo Ricardo Leitner 2018-02-26 12:34:48 UTC
(In reply to Xin Long from comment #3)
> (gdb) select-frame 5
> (gdb) p port->ifinfo
> $1 = (struct team_ifinfo *) 0x0
> 
> static bool __team_port_str(struct team_port *port,
>                             char **pbuf, size_t *pbufsiz)
> {
>         uint32_t ifindex = team_get_port_ifindex(port);
>         struct team_ifinfo *ifinfo = team_get_port_ifinfo(port); <--- NULL
> 
>         return __buf_append(...
>                             team_get_ifinfo_ifname(ifinfo), <--- crash

That's interesting, and odd. As it had __buf_append() in the call stack, I assumed that that had worked. I wonder how this call stack could happen then, because that expression must be evaluated before the function call.

Comment 5 Xin Long 2018-02-26 13:03:52 UTC
(In reply to Marcelo Ricardo Leitner from comment #4)
> (In reply to Xin Long from comment #3)
> > (gdb) select-frame 5
> > (gdb) p port->ifinfo
> > $1 = (struct team_ifinfo *) 0x0
> > 
> > static bool __team_port_str(struct team_port *port,
> >                             char **pbuf, size_t *pbufsiz)
> > {
> >         uint32_t ifindex = team_get_port_ifindex(port);
> >         struct team_ifinfo *ifinfo = team_get_port_ifinfo(port); <--- NULL
> > 
> >         return __buf_append(...
> >                             team_get_ifinfo_ifname(ifinfo), <--- crash
> 
> That's interesting, and odd. As it had __buf_append() in the call stack, I
> assumed that that had worked. I wonder how this call stack could happen
> then, because that expression must be evaluated before the function call.
Maybe ifinfo->ifname (offset) was just a value as the parameter, team_get_ifinfo_ifname didn't yet dereference it (access the memory), until vsnprintf/strlen did that.

Comment 6 Xin Long 2018-07-02 11:39:06 UTC

*** This bug has been marked as a duplicate of bug 1563155 ***


Note You need to log in before you can comment on or make changes to this bug.