Problems using arrays as parameters

[hermann-krumrey-andrena]

Hi, we're having issues using arrays as parameters to our mocks (Specifically UUIDs from the google/uuid package, which are just byte[16]).

Here's a minimal example to reproduce the issue:

type MinimalMock interface {
    DoSomething(myBytes [16]byte) string
}

func TestMinimal(t *testing.T) {
    mockio.SetUp(t)
    myMock := mockio.Mock[MinimalMock]()
    myBytes := [16]byte{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}

    mockio.WhenSingle(myMock.DoSomething(myBytes)).ThenReturn("test")

    result := myMock.DoSomething(myBytes)
    fmt.Println(result)
}

and the output:

=== RUN   TestMinimal

    reporter.go:26: Wanted, but not invoked:
            MinimalMock.DoSomething(Equal[[16]uint8])
        There were 1 invocations on this method:
            MinimalMock.DoSomething([110 22 130 0 0 0 0 0 1 2 3 4 5 6 7 8])
--- FAIL: TestMinimal (0.00s)

FAIL

As you can see, it seems like the values in the array are shifted to the right before being matched.

[ovechkin-dm]

Thanks for a feedback. I already working on this issue. Apparently it has something to do with wrong input arguments alignment on stack. It is not easy to fix, but I am working on it. For now my suggestion is to use pointers instead of values for method arguments (ofc as a temp workaround)

[ovechkin-dm]

Could you please provide cpu architecture and OS you are running tests on?

[hermann-krumrey-andrena]

Thanks for looking into the issue.

I'm using Linux (specifically Arch Linux) with the following lscpu output:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 7 PRO 5850U with Radeon Graphics
    CPU family:          25
    Model:               80
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            0
    Frequency boost:     enabled
    CPU(s) scaling MHz:  44%
    CPU max MHz:         4505.0781
    CPU min MHz:         1600.0000
    BogoMIPS:            3794.18
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc
                         a cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall n
                         x mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_go
                         od nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl p
                         ni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe
                          popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy sv
                         m extapic cr8_legacy abm sse4a misalignsse 3dnowprefetc
                         h osvw ibs skinit wdt tce topoext perfctr_core perfctr_
                         nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate
                          ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 sm
                         ep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflusho
                         pt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc c
                         qm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf 
                         xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock n
                         rip_save tsc_scale vmcb_clean flushbyasid decodeassists
                          pausefilter pfthreshold avic v_vmsave_vmload vgif v_sp
                         ec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_r
                         ecov succor smca fsrm
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   256 KiB (8 instances)
  L1i:                   256 KiB (8 instances)
  L2:                    4 MiB (8 instances)
  L3:                    16 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-15
Vulnerabilities:         
  Gather data sampling:  Not affected
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec rstack overflow:  Mitigation; safe RET, no microcode
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer
                          sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIB
                         P always-on, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

[lalvincz]

by the way, we were very happy to find this library for mocking in go. most other mocking libraries use explicit code generation for the mocks, which makes it somehow cumbersome, especially if you rename an interface or a method. so thanks a lot for this library! Lars (team mate of Hermann)

[ovechkin-dm]

Thanks for kind words, It is good to know that you are using this library. I was also surprised with the lack of similar solution when I entered the golang world. Issue is resolved, could you please confirm that everything is working for you? I added test scenario for a case you described. https://github.com/ovechkin-dm/mockio/blob/main/tests/mocking/mock_test.go

[lalvincz]

That was fast - thanks a lot! we will check it and come back at you. and also interesting to hear that you also have no explanation for the situation, maybe code generation for mocks is the typical go way? or maybe is it easier with recent go versions? Anyway, good to finally have a library for that :)

[lalvincz]

We just checked it, it works now as expected 👍

[ovechkin-dm]

Good. Closing then.