Internal error (40101) when pre-compiling a program based on pro*c

This article was originally posted in my csdn.net blog on 7 May 2009.


A pro*c based program was to be deployed on an AIX machine (AIX 5.3+Oracle 10.2.0.3) for test purpose, but unfortunately I encountered an error when pre-compiling the program. The error message was as follows:

System default option values taken from: /ora10g/product/102/precomp/admin/pcscfg.cfg

INTERNAL ERROR: Failed Assertion [Code=40101]


I googled this information and found there was somebody having the same problem on OTN: http://forums.oracle.com/forums/thread.jspa?messageID=2561956

I tried those programs in above OTN page and got the same results. According to some comments, the compile mode of xlc should be 64 bit, and the define option of proc should include __64BIT__. But both were eligible for our situation. Read this page thoroughly but there was no other useful information.

Our program doesn't use pid_t directly, but the header file pthread.h is included. Thus I wrote another test program like this:

/*abc.pc*/
#include <pthread.h>
#include <stdio.h>
main()
{
printf("hello\n");
}

Unfortunately the same error occured when the command 'proc abc' was issued. But It's ok when the included header file pthread.h was removed.

At last I turned to oracle technicians for help, and they gave me an FAQ on metalink:

Metalink Doc ID: 263286.1
Cause:
The Pro*C source code contains a long CASE statement or a long IF ELSE statement
Solution:
Split the CASE or the IF ELSE statement
References
Bug 530920 - SEGMENTATION FAULT(COREDUMP) WHEN PRECOMPILING VERY LONG IF STATEMENTS

Login metalink to get more details.


That is to say, there is a bug for oracle proc. I checked our program, there are some a little bit long switch, case, and if else statements. Therefore, I modified them to assure that only about 30 lines were included in the longest switch, case and if else statements. But the error still persisted.

Just when I was having no idea about that, I found some general oracle commands, such as sqlplus/exp/imp, couldn’t be used either. But all the command worked well when I switched to oracle user. According to this clue, I immediately switched to oracle use and pre-compile the above test program. It's ok! And then I moved the original program to oracle user and compilation was also successfully done.

And I also found it was ok as long as the user was in dba group. Therefore we could make a conclusion for this problem: there were some privilege problems when the oracle was installed and some directories or files couldn’t not be accessed by users in other group.