PR merge blocked with message: Control Freak: null

[Steven Whitman]

One of the PR that was created is showing a disabled merge button with the hover message of Control Freak: null and when you click the Merge button this stack trace is displayed:

Control Freak: null at com.bitbooster.hook.C.buildResult(C.java:184) at com.bitbooster.hook.C.parse(C.java:121) at com.bitbooster.hook.ControlFreakHook.validateChange(ControlFreakHook.java:743) at com.bitbooster.hook.ControlFreakHook.check(ControlFreakHook.java:590) at com.bitbooster.hook.ControlFreakHook.preUpdate(ControlFreakHook.java:232) at com.bitbooster.hook.ControlFreakHook.preUpdate(ControlFreakHook.java:164) 

Disabling Control Freak for Regular Repos allows the merge. I haven't found any other items I can disable or change that allows the merge. I did notice that the "Pull Request Merge Checks" is enabled and I can't see any means to disable it. Since this was a merge I tried changing some of the settings in that section but the merge was still blocked.

The PR was declined and recreated and but this did not fixed whatever was wrong. Other users do not seem to be having any issues. This developer as well as the others that have successfully created a PR.and merged them are merging branches from a fork to the source repo.

When the PR was created we were running Control Freak version 2019.08.30 or 2019.08.31 (sorry, forgot to note it before updating to the latest 2019.10.12. Our server running is Atlassian Bitbucket v6.3.2.

Even after the update the issue still occurred with this one developer for this particular PR. I don’t know if it will occur with other PRs created by this developer.

[Julius Davies [bit-booster.com]]

Hi Steven Whitman,

‌

Thanks for this bug report. I haven’t been able to replicate it yet, but with that stacktrace you included, I can probably put out a release with enhanced error messages around the problem area that helps me get to the root cause even without a full replication on my side.

First, a few questions:

Is the bug only occurring in a single pull-request of a single repository?

Or several pull-requests within a single repository?

Or is the bug widespread and occurs in many repositories?

‌

‌

‌

[Julius Davies [bit-booster.com]]

Hi Steven Whitman,

v2019.10.20 released just now. We think v2019.10.20 should resolve this issue.

Again, thanks for reporting this bug!

[Steven Whitman]

Hi, to answer your previous questions

• We have only seen it on a single developers pull request for a specific commit. When that PR was deleted and a new PR created by this developer using the same from/to branch commits the problem reappeared. Other developers creating different PRs did not have this issue. We didn’t try another developer using the first developers commits.

We’ll update to the latest and let you know if we have any issues. I’m not expecting any as this seems to have been a one off only partially reproducible bug.

‌

[Julius Davies [bit-booster.com]]

One way to reproduce the bug would be to use “git merge --squash” and not adjust the resulting commit message at all. That would trip up my c.parse() routine. But “git merge --squash” is so rarely used by developers that I’m not surprised this bug has never been triggered until now.

This bug report caused me to stare really hard at the C.parse() routine in the commit-parsing logic, and after a good long stare I spotted some problems in that code. I’m feeling confident this fixes your issue.

‌

[Steven Whitman]

I suspect that wasn’t the only way to reproduce this bug because I’d be surprised if this developer used git merge --squash although I will follow up with them to see if that is what they did. This particular PR had 4 commits present. Since this was a parsing issue with the commit message I assume here are the 4 commit messages that were present.

• Fix sobel large image Fix sobel large image implementation

  Update src/ip/ip/sobel95/proc/x64/xmmlarge.asm appropriate to reflect API
  which allocates temporary storage on heap (instead of stack)

• Fix sobel large for x86

  Update src/ip/ip/sobel95/proc/x86/{mmxlrgin.c,xmmlarge.asm}
  For x86, revert to allocating temporary storage on stack (since
  it won't be too large for x86).

• Update struct size used for sobel large

  In src/ip/ip/sobel95/soblgstr.c, update structure
  stackFrameStructPlusPrioritiesDefinedForSize
  to
  reflect struct in xmmlarge.asm

• Increase temporary storage size for sobel large

  In src/ip/ip/sobel95/soblgstr.c, increase storage size to
  18*width to accommodate usage in xmmlarge.asm

  Also, fix storage size allocation in
  src/ip/ip/sobel95/proc/x64/xmmlarge.asm

‌