Bytecode Generation Process
In the build process of an ArkTS project, Ark bytecode files (*.abc) are generated using the es2abc compiler component in the toolchain.
In the Hvigor build, the es2abc compiler is automatically invoked to convert TypeScript/JavaScript source code into bytecode files (*.abc) that can be executed by Ark Virtual Machines (VMs). These generated files are then packaged into HAPs/HARs/HSPs and loaded by the system.
This FAQ summarizes the common exception scenarios encountered during actual bytecode compilation and provides the cause analysis and help you locate issues more efficiently.
Compilation Error: "owns a higher api version"
Symptom
The "owns a higher api version" error is reported during compilation.
> hvigor ERROR: ArkTS:ERROR Failed to execute es2abc. Error Message: Error: The input abc file '/Users/xxx/Desktop/Git/KnowChat_Harmony/oh_modules/.ohpm/wrapper@xnnuf1xhgb6dfmf+4nqatekk3somopridtvlx+rvty0=/oh_modules/wrapper/ets/modules.abc' owns a higher api version or a higher sdkReleaseType compared to current compilation process. [/Users/xxx/Desktop/Git/KnowChat_Harmony/oh_modules/.ohpm/wrapper@xnnuf1xhgb6dfmf+4nqatekk3somopridtvlx+rvty0=/oh_modules/wrapper/ets/modules.abc] Error: The input abc file '/Users/xxx/Desktop/Git/KnowChat_Harmony/oh_modules/.ohpm/@nertc+nertc_sdk@x07imzcfiusn4dyjfe46yg2t+btahwg70+p5ft9p+7y=/oh_modules/@nertc/nertc_sdk/ets/modules.abc' owns a higher api version or a higher sdkReleaseType compared to current compilation process. [/Users/xxx/Desktop/Git/KnowChat_Harmony/oh_modules/.ohpm/@nertc+nertc_sdk@x07imzcfiusn4dyjfe46yg2t+btahwg70+p5ft9p+7y=/oh_modules/@nertc/nertc_sdk/ets/modules.abc] Error: The input abc file '/Users/xxx/Desktop/Git/KnowChat_Harmony/oh_modules/.ohpm/wrapper@xnnuf1xhgb6dfmf+4nqatekk3somopridtvlx+rvty0=/oh_modules/wrapper/ets/modules.abc' owns a higher api version or a higher sdkReleaseType compared to current compilation process. The size of programs is expected to be 434, but is 432
Possible Causes
The compatible version of the bytecode HAR package is later than that of the project.
Solution
Check the value of the compatibleSdkVersionStage field in the build-profile.json5 files of both the project and the HAR package. Adjust the compatibleSdkVersionStage value in the project to be greater than or equal to the value specified in the HAR package.
Compilation Error: "Field {&harname/Index&1.0.0.moduleRecordIdx} has different value"
Symptom
The "Field {&harname/Index&1.0.0.moduleRecordIdx} has different value" error is reported during compilation.
hvigor Finished :entry:default@DoNativeStrip... after 258 ms
> hvigor Finished :entry:default@CacheNativeLibs... after 622 ms
> hvigor ERROR: Failed :entry:default@CompileArkTS...
> hvigor ERROR: ArkTS:ERROR Failed to execute es2abc.
Error Message: Failed to emit /Users/DevEcoStudioProjects/FastSDKDemo/entry/build/default/intermediates/loader_out/default/ets/modules.abc, error: Field {&finesdk/Index&1.0.0.moduleRecordIdx} has different value.
If you're using any cache file generated by older version of SDK, please try cleaning the cache files and rebuild
GenerateProgram Failed! Possible Causes
The Record field in the .abc file conflicts due to inconsistent dependency library versions.
Common triggering scenarios include:
The useNormalizedOHMUrl field in the project-level build-profile.json5 file is set to true.
If this happens in the build-profile.json5 file, the toolchain will normalize module URLs.
If the Record field in the HAR package is inconsistent with the actual dependency of the project, a conflict occurs.
The ohpm cache or compilation cache is not completely cleared. As a result, the same HAR package has two different versions.
Leftover HAR and ABC data from old versions causes the Record index validation in the es2abc compiler to fail.
Solution
When using cross-module import methods, set useNormalizedOHMUrl to false in the build-profile.json5 file.
Clear the ohpm and compilation cache, download the ohpm package, and rebuild the project by following these steps:
- Click Build > Clean Project in the menu bar, or run the command ohpm clear on the console.
- Click File > Invalidate Caches... in the menu bar. In the displayed dialog box, select all options, execute the commands, and restart.
- Run the ohpm install command on the console.
- Click Build > Rebuild Project in the menu bar.
Compilation Exception Without Specific Error Logs
Symptom
"Failed to execute es2abc" is displayed during compilation, but no valid error log is output on the console.
Possible Causes
In certain cases, the es2abc compiler may exit abnormally without generating logs.
The triggering conditions are related to the code structure, resource consumption, and internal behavior of the compiler. Common causes include but are not limited to the following.
| Category | Typical Symptom | Known Triggering Condition |
|---|---|---|
| Stack overflow | Deep recursion | Deep syntax nesting and complex expression chains. |
| Out of memory (OOM) | Abnormal exit without logs | Definition of ultra-large files, massive objects, and functions. |
| Uncaught parser exception | Process interruption without output | Edge-case syntax patterns |
Solution
Windows: Checking Event Viewer for Crash Logs
Press Win + R, enter eventvwr.msc, and open Event Viewer.
In the left navigation pane, expand Windows Logs > Application.
In the log list on the right, look for entries that meet the following criteria:
- Source: Application Error
- Faulting application name: es2abc.exe
Double-click the log to view details.
If the exception code is 0xc00000fd, the crash is caused by a typical stack overflow.
macOS: Checking Console for Crash Reports
Open the Console application.
In the left sidebar, expand either:
- Crash Reports or User Reports.
Locate reports in the list whose names contain es2abc.
Double-click the report to view the crash stack.
If a function is called multiple times consecutively (for example, A → A → A...), the stack may overflow due to deep recursion.
Stack Overflow Scenarios and Troubleshooting
Typical code structures that may trigger stack overflow include:
Deep syntax nesting
- Consecutive nested if/else statements
- Multi-layer nested arrays or objects, for example, [[[[...]]]].
- Automatically generated deeply nested structures (especially those generated by DSL or code generators)
Repeated abnormal strings or symbols
- Lines with a large number of repeated symbols, for example, multiple lines of consecutive !!!!!!!!!!.
Overlong chain expression
- A large number of consecutive type assertion chains. For example, a as Int as Int as Int ....
- Other similar chain operations that cause an extremely deep expression tree
When a stack overflow occurs, check the crash log for repeated invocations of the same function. If the same call chain is repeated dozens or even hundreds of times, the parser triggers an abnormally deep recursion while processing a piece of source code. Finally, the call depth exceeds the limit of the stack space, causing a stack overflow and crash.
Further Troubleshooting Suggestions
If the crash log points to a stack overflow, check whether the code contains the following structures:
- Hundreds of layers or deeper if-else/branch nesting.
- Deeply nested parentheses, arrays, or objects
- A large number of consecutive type conversion chain calls
- Meaningless repetitive structures (such as consecutive symbols) in auto-generated code
These structures cause the parser to generate extremely deep recursion when building the Abstract Syntax Tree (AST), ultimately triggering a stack overflow.