Marginplot raises method error for certain transfer functions

[KronosTheLate]

The error is the following:
"ERROR: MethodError: no method matching _extract_group_attributes(::Int64, ::Array{Float64,1}, ::Array{Float64,1})",
and is produced for certain transfer functions.

In reproducing this error, tested different numerators and denominators of s in the transfer function. The denominator polynomial is in all cases given by the coefficients [1; 1; 1; 1], so of degree 3. The error was successfully reproduced for the following numerator polynomials of degree 1, 3 and 5:

[1; 1]
[1; 1; 1; 1]
[1; 1; 1; 1; 1; 1]

The margin function does some time return the right values. It does however sometimes return inexact errors like Int64(NaN)
or Int64(1.0116379797662072). From what I can tell now, margin sometimes worked as expected when I define the transfer function as some fraction with s, where s is defined with s=tf("s") (script in VSCode), not at all when I define the transfer function with arrays of coefficients as seen above (script in VSCode), and not at all in the REPL. I have also gotten ERROR: BoundsError: attempt to access 1-element Array{Float64,1} at index [100] a couple of times. I have no idea what causes this.

My ControlSystems version is 0.8.0. I have copied the return from versioninfo() below:

Julia Version 1.5.2
Commit 539f3ce943 (2020-09-23 23:17 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-9.0.1 (ORCJIT, skylake)

[mfalt]

Could you post a minimal example where this occurs, that makes it easier for us to test and afterwards verify if it's solved. Does the behavior change if you use 1.0 somewhere instead of 1?

[KronosTheLate]

Sorry about taking long to respond:

First of all, changing 1 to 1.0 does not change the error.

Secondly, the errors shown were found in previous versions of the package, but are reproduced with the latest update.

I want to show the screenshot below before going into MWE.

This warning is printed whenever the error is encountered, and it looks relevant to me as I am pretty sure that these examples only have 1, possibly two margins. The margin function also only finds a single margin, shown later.

In trying to recreate the problem I have found the two following cases where the error occurs. Not that this is a pluto notebook, with the output above the input. The same errors have also been reproduced in VSCode and with the GR backend:

In this first case, the error persists when I change coefficients. This explains why I encountered it "in the wild" - because my transfer function was of this form with different coefficients.

In this second case, changing the coefficients made the problem go away most of the time, but not in all cases. This is weird IMO as I don't see what is so special about only ones as the coefficients.

As you can see, the margins are found correctly by the margin function in both cases. As mentioned in the original post, margin returned inexact errors in the past, but I could not reproduce the error from margin now.

A final information is that in the original post I was able to recreate the problem with polynomials of degree 1, 3 and 5 as numerators. I was not able to reproduce this today.