Directly from the test case i'm attaching to this bug:

  /* We create a composition with an operation and three sources. The operation
   * contains a videomixer instance and the three sources are videotestsrc's.
   *
   * One of the sources, source2, contains videotestsrc inside a bin. Initially
   * the bin doesn't have a source pad. We do this to exercise the dynamic src
   * pad code path in gnlcomposition. We block on the videotestsrc srcpad and in
   * the pad block callback we ghost the pad and add the ghost to the parent
   * bin. This makes gnlsource emit no-more-pads, which is used by
   * gnlcomposition to link the source2:src pad to videomixer.
   *
   * We start with the composition containing operation and source1. We preroll
   * and then add source2. Source2 will do what described above and emit
   * no-more-pads. We connect to that no-more-pads and from there we add source3 to
   * the composition. Adding a new source will make gnlcomposition deactivate
   * the old stack and activate a new one. The new one contains operation,
   * source1, source2 and source3. Source2 was active in the old stack as well and
   * gnlcomposition is *still waiting* for no-more-pads to be emitted on it
   * (since the no-more-pads emission is now blocked in our test's no-more-pads
   * callback, calling gst_bin_add). In short, here, we're simulating a race between
   * no-more-pads and someone modifying the composition.
   *
   * Activating the new stack, gnlcomposition calls compare_relink_single_node,
   * which finds an existing source pad for source2 this time since we have
   * already blocked and ghosted. It takes another code path that assumes that
   * source2 doesn't have dynamic pads and *BOOM*.
   */