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

We want to deploy a pro*c based program on a AIX machine, with AIX5.3+Oracle 10g(10.2.0.3), but unfortunately we encountered an error when pre-compiling the program. The error message is 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 is 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 are eligible for our situation. Read this page thoroughly, and there is 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 it to assure only about 30 lines are inclued 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 can't be used. 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 program to oracle user and compilation was also successfully done.

 

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