IOS builds failing (timeout?) Aug 27

[Dave Dyer]

I've been away for a week, creating a test build to validate your latest changes, my IOS builds
now fail after 30 minutes, presumably due to a timeout.

/Intermediates/ArchiveIntermediates/Develop/IntermediateBuildFilesPath/Develop.build/Release-iphoneos/Develop.build/Objects-normal/arm64/com_codename1_io_gzip_InfTree.o
** BUILD INTERRUPTED **
Failed xcodebuild step

My builds were taking less than 10 minutes last week.

[Dave Dyer]

Attached is the entire error log.  The timeout occurs during the xcode build, which I haven't seen before.

[Shai Almog]

I saw another report for this. It might be a regression due to the new xcode changes e.g. the null check RFE. We need to look into that.

[Steve Hannah]

The recent change, which removes null checks from methods (and instead relies of signals), added an #ifdef macro to each method, which may have affected LLVM's compile performance.  That's just speculation as past experience has taught me that LLVM can be ground to a halt by the strangest little things.  I have just committed a change that removes this ifdef - it will be deployed next server update.  Hopefully this resolves the issue.  I'm not experiencing this problem with any of my test projects.

Steve

On Sun, Aug 27, 2017 at 9:03 PM, Shai Almog <shai....@gmail.com> wrote:

I saw another report for this. It might be a regression due to the new xcode changes e.g. the null check RFE. We need to look into that.

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/f6892c3a-5acd-4130-bf70-548d7904c00f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[Dave Dyer]

I'm trying this out with my local build setup, and one thing that is apparent is that the "expected statement" bug
due to dangling labels at the end of methods is much more of a problem - those null checks which are
now gone were creating a useful end-of-method padding.

There's already a fix for that problem in one of my other push requests.

[nickk...@gmail.com]

I can't send any iOS builds, the error log is different depending on the project:

BluekeyInspect-dummy.o)) was built for newer iOS version (7.0) than being linked (6.0)
Undefined symbols for architecture armv7:
  "_com_codename1_components_FloatingHint___INIT_____com_codename1_ui_TextField", referenced from:
      _com_bluekey_app_forms_Home_lambda$init$0___com_bluekey_app_forms_Home in com_bluekey_app_forms_Home.o
      _com_bluekey_app_forms_InspectionForm_addItem___com_codename1_ui_events_ActionEvent in com_bluekey_app_forms_InspectionForm.o
      _com_bluekey_app_forms_PhotoEditor_beforeShow__ in com_bluekey_app_forms_PhotoEditor.o
      _com_bluekey_app_forms_RoomSelection_addNewRoom___com_codename1_ui_events_ActionEvent in com_bluekey_app_forms_RoomSelection.o

or:

CompileC build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/Objects-normal/arm64/com_codename1_io_gzip_InfTree.o OurConference-src/com_codename1_io_gzip_InfTree.m normal arm64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    cd /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist
    export LANG=en_US.US-ASCII
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch arm64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=c99 -Wno-trigraphs -fpascal-strings -O3 -Wno-missing-field-initializers -Wno-missing-prototypes -Werror=return-type -Wno-implicit-atomic-properties -Werror=deprecated-objc-isa-usage -Werror=objc-root-class -Wno-arc-repeated-use-of-weak -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wno-int-conversion -Wbool-conversion -Wno-enum-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wundeclared-selector -Wno-deprecated-implementations -DCOCOAPODS=1 -DNS_BLOCK_ASSERTIONS=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -miphoneos-version-min=6.0 -g -fvisibility=hidden -Wno-sign-conversion -iquote /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/OurConference-generated-files.hmap -I/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/OurConference-own-target-headers.hmap -I/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/OurConference-all-target-headers.hmap -iquote /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/OurConference-project-headers.hmap -I/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/BuildProductsPath/Release-iphoneos/include -I/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/Pods/Headers/Public -I/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/DerivedSources/arm64 -I/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/DerivedSources -F/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/BuildProductsPath/Release-iphoneos -isystem /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/Pods/Headers/Public -include /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/PrecompiledHeaders/OurConference-Prefix-bulyyjxjlqzitlatzxfhwfmmgccm/OurConference-Prefix.pch -MMD -MT dependencies -MF /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/Objects-normal/arm64/com_codename1_io_gzip_InfTree.d --serialize-diagnostics /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/Objects-normal/arm64/com_codename1_io_gzip_InfTree.dia -c /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/OurConference-src/com_codename1_io_gzip_InfTree.m -o /var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build6740292962730382277xxx/dist/build/Build/Intermediates/ArchiveIntermediates/OurConference/IntermediateBuildFilesPath/OurConference.build/Release-iphoneos/OurConference.build/Objects-normal/arm64/com_codename1_io_gzip_InfTree.o
Failed xcodebuild step

Not sure how things are tested before being pushed live, but this kind of critical failure is causing serious consequences for me and my clients and it resulting in us evaluating other alternatives to Codename One so we can build locally and at least have some action that we can take when issues arise.

I opened a ticket that got closed as won't fix for providing the source code when a build fails. In this instance I could help troubleshoot the the problem and perhaps provide a fix back again. As it is I can only twiddle my thumbs for 24 hours waiting for a fix to arrive, which shows the huge flaw that a dependency on a build server introduces.

[Dave Dyer]

Another problem is this:

nativeMethods.m:#include "CodenameOne_GLViewController.h"

there is no longer a file with that name, and this is the only reference to it.

[Dave Dyer]

The big problem for my build, probably the fatal one, is that last week's builds generated this code for enums

JAVA_OBJECT __VALUE_OF_yspahan_YspahanConstants_ymisc(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT value) {
        JAVA_ARRAY values = (JAVA_ARRAY)get_static_yspahan_YspahanConstants_ymisc__VALUES(threadStateData);
    JAVA_ARRAY_OBJECT* data = (JAVA_ARRAY_OBJECT*)values->data;

whereas this week's builds generate this code

JAVA_OBJECT __VALUE_OF_yspahan_YspahanConstants_ymisc(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT value) {
        JAVA_ARRAY values = (JAVA_ARRAY)get_static_yspahan_YspahanConstants_ymisc_ENUM_VALUES(threadStateData);
    JAVA_ARRAY_OBJECT* data = (JAVA_ARRAY_OBJECT*)values->data;
    int len = values->length;

[Dave Dyer]

> Not sure how things are tested before being pushed live, but this kind of critical failure is causing serious consequences for me and my clients and it resulting in us > >evaluating other alternatives to Codename One so we can build locally and at least have some action that we can take when issues arise.

>

>I opened a ticket that got closed as won't fix for providing the source code when a build fails. In this instance I could help troubleshoot the the problem and perhaps provide >a fix back again. As it is I can only twiddle my thumbs for 24 hours waiting for a fix to arrive, which shows the huge flaw that a dependency on a build server introduces.

Enterprise customers (those who pay more) have the option of using a stable build.  The rest
of us are involuntary parts of the Q/A process.  You have to cut them some slack, they're
a small company trying to do a lot, but they do make mistakes like this from time to time.

[Steve Hannah]

Nick,

Those two error reports look unrelated to each other.  One is likely related to including a native lib that is built for 32 bit and the other is something else - perhaps a timeout.

I looked in the issue tracker but can find no sign of an issue posted by you on either of these.

If you do a versioned build against 3.7, do you get the same issues? 

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/246f32fb-f88e-46ce-bbf8-63eb84d00aaa%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steve Hannah]

Dave,

Another problem is this:

nativeMethods.m:#include "CodenameOne_GLViewController.h"

I agree that this probably doesn't belong in the nativeMethods.m file since nativeMethods.m is part of ParparVM and  CodenameOne_GLViewController.h is part of CN1 --- ParparVM shouldn't depend on CN1.  

Nonetheless, right now it looks like nativeMethods.m does need to use a few things from CN1, and that's why the dependency is there.

I'm not sure where the second version would come from.  Perhaps different versions of the JDK produce different naming conventions for generating enums.  The class in question (yspahan.YspahanConstants), how was it compiled?  E.g.  Is the source actually part of a Codename One project, or was it compiled in another way and converted to, for example, a cn1lib?  What version of the JDK was used to compile it, and what were Java source and bytecode versions were being targeted?

I have built  several projects with the "Include Source" box checked, and then done a grep for _ENUM_ but there are no results.  Meaning that my builds are still producing the first version you posted.

Steve

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/60a7c411-20e3-4f10-8d31-d6199d226160%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[nickk...@gmail.com]

Hi Steve,

I'm also getting this error (as the entire error log) on 'Latest':

Exception on appending to log: java.io.IOException: Stream closed

If I send a 3.7 build it works but I need to strip out a couple of things from my app that use new features.

Its frustrating because I've come back from holiday with three lines of code to change in order to finish a client project and get paid and I can't do it because builds are failing. 

I realise none of this is done on purpose and of course have my own fair share of issues that crop up in my code, my grumble was more about how we (non-enterprise CodenameOne developers) become impotent when issues like this happen rather than that they happen at all. Simply allowing access to source code when builds fail would help get more eyes on the issue and give us the option to troubleshoot and fix these things.

I've been away for a week, once builds started failing yesterday I've been sending builds that worked before I left and I haven't touched since to exclude anything that I might've done.

[Dave Dyer]

I can't do versioned builds.  I have a fossil copy of the parpavm build process from the era when I proposed
all the fixes that you haven't installed.

The labels fix I'm referring to is in https://github.com/codenameone/CodenameOne/pull/2108

[Dave Dyer]

Nonetheless, right now it looks like nativeMethods.m does need to use a few things from CN1, and that's why the dependency is there.

The dependency is there, but the file is not, at least in my environment.  As I said, I'm working in my
own fork of the parpavm build code, updated from githib, and a  working fossil version that I have
not updated.

The big problem for my build, probably the fatal one, is that last week's builds generated this code for enums

JAVA_OBJECT __VALUE_OF_yspahan_YspahanConstants_ymisc(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT value) {
        JAVA_ARRAY values = (JAVA_ARRAY)get_static_yspahan_YspahanConstants_ymisc__VALUES(threadStateData);
    JAVA_ARRAY_OBJECT* data = (JAVA_ARRAY_OBJECT*)values->data;

whereas this week's builds generate this code

JAVA_OBJECT __VALUE_OF_yspahan_YspahanConstants_ymisc(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT value) {
        JAVA_ARRAY values = (JAVA_ARRAY)get_static_yspahan_YspahanConstants_ymisc_ENUM_VALUES(threadStateData);
    JAVA_ARRAY_OBJECT* data = (JAVA_ARRAY_OBJECT*)values->data;
    int len = values->length;

I'm not sure where the second version would come from.  Perhaps different versions of the JDK produce different naming conventions for generating enums.  The class in question (yspahan.YspahanConstants), how was it compiled?  E.g.  Is the source actually part of a Codename One project, or was it compiled in another way and converted to, for example, a cn1lib?  What version of the JDK was used to compile it, and what were Java source and bytecode versions were being targeted?

I think it's two chunks of code generated by parpam that are not quite coordinated, the function name and the
reference to the function are both constructed in the bowels of parpavm's code.

I am handicapped by the fact that failed builds do not deliver the sources that failed,
and that successful builds do not deliver the log file for the build.  I've complained
about this before.

[Steve Hannah]

The ParparVM source code also contains no results if you grep _ENUM_ .  That part is constructed by javac and propagated through.

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/424c3c36-956e-465a-86b7-a80fe85afeec%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dave Dyer]

On Monday, August 28, 2017 at 4:33:43 PM UTC-7, Steve Hannah wrote:

The ParparVM source code also contains no results if you grep _ENUM_ .  That part is constructed by javac and propagated through.

Both sets of code were generated from the same client binaries, so there is no possibility that
different versions of javac could be involved.   I saw the source of this mysterious "ENUM" once
and I remember it was not lexically obvious.   Here are the two source files generated by the old and current
versions of parpavm, and the .java and .class files from which they were generated.

[Dave Dyer]

On Monday, August 28, 2017 at 4:33:43 PM UTC-7, Steve Hannah wrote:

The ParparVM source code also contains no results if you grep _ENUM_ .  That part is constructed by javac and propagated through.

This is in the code for "{enum}.values() which is wholly constructed by parpavm.

[Shai Almog]

@Nick we changed the signature of the method to reference TextArea instead of TextField. Update the client libs and send a new build to resolve that first error.

[xha...@googlemail.com]

I´m STILL unable to build IOS apps for like 3 months now, cause i´m constantly getting build timeout OR "Exception on appending to log: java.io.IOException: Stream closedFailed xcodebuild step"

I need to send like 10 builds ( one build takes up to 25 minutes!!!! ) to get one successfull one.

[Shai Almog]

That's troubling. 

I was sure this was resolved for you by now. Although that's probably unrelated to the current regression and more related to Daves problem as your app is pretty monolithic too.

It's hard to tell if Dave's PR's will make a difference as building something can be fast locally and slow on the servers (and visa versa) I'm not sure why but it just acts that way.

[Dave Dyer]

Todays update did not improve my situation.    Builds are still much slower than before, and time out.

[Steve Hannah]

If you add the build hint ios.includeNullChecks=true does that help?

On Fri, Sep 1, 2017 at 8:47 AM, Dave Dyer <ddyer-...@real-me.net> wrote:

Todays update did not improve my situation.    Builds are still much slower than before, and time out.

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/2ed04778-5782-46dd-b1e7-59b81cce4415%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Web Lite Solutions Corp.

[Dave Dyer]

Yes, adding the hint fixed the build.

[Steve Hannah]

I have now changed the default on this build hint to "true", pending further investigation on why it would be causing these problems.  That change will be reflected in the next server update.

Steve

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/cbbf9505-e64d-4041-b5c4-f099d6792d87%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

[Dave Dyer]

This is the point where I found it necessary to add an ENUM to the code being generated

in ByteCodeClass.java

        if (isEnum) {
            b.append("JAVA_OBJECT __VALUE_OF_").append(clsName).append("(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT value) {\n    ");
            b.append("    JAVA_ARRAY values = (JAVA_ARRAY)get_static_").append(clsName).append("_ENUM_VALUES(threadStateData);\n");
            b.append("    JAVA_ARRAY_OBJECT* data = (JAVA_ARRAY_OBJECT*)values->data;\n");

I haven't discovered where the name of the static enum values variable comes from.

[Steve Hannah]

The actual static field name is added by javac, and the current version (without adding _ENUM_) works with all of our tools, as far as I know.   Making the change you suggest would break everything.

 The question is, why is your local toolchain generating these static fields with a different naming convention than our toolchain does?  How was the .class file in question produced?  

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/050147d5-d79f-4bb6-898d-c5a670c6b4a6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dave Dyer]

On Friday, September 1, 2017 at 2:14:34 PM UTC-7, Steve Hannah wrote:

The actual static field name is added by javac, and the current version (without adding _ENUM_) works with all of our tools, as far as I know.   Making the change you suggest would break everything.

 The question is, why is your local toolchain generating these static fields with a different naming convention than our toolchain does?  How was the .class file in question produced?  

I use the \bin directory that would be used for  debugging, without running the

build.xml script.   I guess that's an adequate explanation

[Dave Dyer]

This gets stranger.  I revived my private build process, using current github sources, with includeNullChecks=false.
It works fine, and at good speed, if I comment out the superfluous labels associated with the "statement expected"
problem.  There are currently 2 in my build.

I'm entertaining the theory that the "statement expected" problem is causing the builds to fail in the
current non-informative way, where previously they at least failed with a recognizable error.

it would really help If I could somehow get a copy of the actual sources your xcode build is failing to build.

[Dave Dyer]

I did two builds of one of my non-broken projects, for which the ONLY difference was changing includeNullChecks true to false,
and comapred the two sets of sources for the xcode projects.  There were a lot of curious differences in the pods project.pbxprod
Maybe that's a clue to what the problem is.

Attached find the two project files.

There were some other differences in two source sets that may offer clues.
manifest.lock contains COCOAPODS: 1.0.1
 or  COCOAPODS: 1.1.0.beta.1

[Dave Dyer]

One other difference between the two builds looks strange, but I can't say it's a problem.  In the "check" case, the locals
generated for a method are all in order.

JAVA_INT online_tantrix_common_GameBoard_formForcedList___R_int(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT  __cn1ThisObject) {
    volatile JAVA_INT ilocals_1_ = 0; /* v1 */
    volatile JAVA_INT ilocals_2_ = 0; /* v2 */
    volatile JAVA_INT ilocals_3_ = 0; /* v3 */
    volatile JAVA_INT ilocals_4_ = 0; /* v4 */
    volatile JAVA_INT ilocals_5_ = 0; /* v5 */
    volatile JAVA_INT ilocals_6_ = 0; /* v6 */
    volatile JAVA_INT ilocals_7_ = 0; /* v7 */
    volatile JAVA_INT ilocals_8_ = 0; /* v8 */
    DEFINE_INSTANCE_METHOD_STACK(6, 9, 0, 9832, 9896);

whereas in the "nocheck" sources, the locals are perturbed into some other order

JAVA_INT online_tantrix_common_GameBoard_formForcedList___R_int(CODENAME_ONE_THREAD_STATE, JAVA_OBJECT  __cn1ThisObject) {
    volatile JAVA_INT ilocals_3_ = 0; /* v3 */
    volatile JAVA_INT ilocals_2_ = 0; /* v2 */
    volatile JAVA_INT ilocals_5_ = 0; /* v5 */
    volatile JAVA_INT ilocals_4_ = 0; /* v4 */
    volatile JAVA_INT ilocals_7_ = 0; /* v7 */
    volatile JAVA_INT ilocals_6_ = 0; /* v6 */
    volatile JAVA_INT ilocals_8_ = 0; /* v8 */
    volatile JAVA_INT ilocals_1_ = 0; /* v1 */
    DEFINE_INSTANCE_METHOD_STACK(6, 9, 0, 9832, 9896);