Oracle Forms & Reports 14.1.2 Patching Issue

During a recent maintenance activity, I patched an Oracle Forms & Reports 14.1.2 environment on Linux. The patching itself completed successfully, but immediately after the restart, Oracle Reports started failing.

At first, the issue looked like a Java or JDK problem. After a full investigation, it turned out to be different.

This blog explains the full story from beginning to end.

Introduction

Initial Objective

The initial goal was simple:

• apply the latest Oracle Fusion Middleware patch bundle
• restart the environment
• validate Forms and Reports services

The patch installation completed without any obvious errors, and patch inventory looked clean.

Issue after patching

Once the environment was started again, Oracle Reports was no longer stable.

Symptoms:

• Reports engine failed to start correctly
• Report execution was failing
• Oracle Reports processes were crashing shortly after startup
• The environment became unstable after patching

This immediately confirmed that the issue was introduced after the Oracle patching activity.

Investigation

The first checks focused on the usual areas:

• WebLogic status
• Reports server startup
• Reports engine diagnostic logs
• process status
• environment variables
• classpath and Java configuration

At this stage, the failure appeared during Reports engine initialization.

Crash Analysis

A deeper review showed JVM crash files (hs_err_pid) being generated.

The important finding was that the crash was not pointing to standard Java code.
It was occurring in the Oracle Reports native library:

• librw.so
• function around kguinit

This was an important clue because it suggested the problem was not a normal Java exception, but a failure in Oracle Reports native components.

JDK Validation

Because the issue started after patching, one possible explanation was a JDK problem.

Several validations were performed:

• Checked active Java paths
• Rolled back JDK version
• Retested with the previous JDK
• Compared behavior before and after JDK rollback

The same crash still happened even after JDK rollback.

That confirmed the issue was not caused by the JDK itself.

Rollback and Reproduction Test

To make sure the Oracle patch was really the trigger, I performed a controlled validation:

• Roll back Oracle patch
• Start environment
• Test Reports
• Reapply Oracle patch
• Retest Reports

Before patch: environment worked fine

After patch: issue was reproduced again.

This confirmed that the problem was patch-related and reproducible.

Real Root Cause Direction

After further analysis, it became clear that the problem was not just a startup configuration issue.

The patch had left the Oracle Reports native layer in an inconsistent state, and the environment needed a relink of Oracle FMW Reports and related shared libraries. I already had the case in the past with older versions (11 and 12), which normally has been solved since (related Oracle KB)!

That explained why:

• Patching succeeded
• Startup partially worked
• But Reports engine crashed in native code

Final Resolution

The final resolution was to relink Oracle FMW Reports.

First, the Reports environment was loaded:

cd $DOMAIN_HOME/reports/bin
. ./reports.sh

Then the Oracle Reports libraries and binaries were rebuilt:

cd $ORACLE_HOME/reports/lib
make -f ins_reports.mk install

This recreated and relinked key Reports components such as:

• librw.so
• librwu.so
• rwserver
• rwrun
• rwclient
• rwbuilder
• rwconverter
• rwcgi
• rwproxy
• rwrqv

After that, the Oracle client shared libraries were rebuilt as well:

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk client_sharedlib

This regenerated the Oracle client shared libraries and symbolic links required by the middleware binaries.

After the relink activity:

• Oracle Reports started correctly
• the engine no longer crashed
• report execution worked again
• the patched environment became stable

So the environment could remain patched and operational, without needing to stay rolled back.

Lessons Learned and key takeaway

This case was a good reminder that post-patching issues are not always caused by:

• Java
• Classpath
• Managed server configuration
• OS changes

Sometimes the real issue is lower-level and sits in:

• Oracle native binaries
• Shared libraries
• Incomplete or inconsistent linking after patching

So, please note that when Oracle Reports crashes inside librw.so after patching, and rollback proves the patch introduced the issue, a relink of Reports and Oracle client shared libraries should be considered as a serious corrective action.

Read more blogs