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.
Friday, September 10, 2010
A conflicting scenario in header file sqltypes.h of Timesten and Informix
This article is originally posted in my csdn.net blog on 7 May 2009.
Oracle is usually used as the phisycal database when TimesTen is working as in-memory database, because the data synchronization is very easy by using cache connect in such situation. But we had to use Informix as the physical database in some projects and we encountered problems just at the compilation stage.
In our product, the database access component which was based on esql includes the header file $INFORMIXDIR/incl/esql/sqltypes.h, and the component for accessing TimesTen was ODBC-oriented and includes the header file $TIMESTEN_HOME/include/sqltypes.h.
These two files are identical in file name but not in content. What's more, there are some identical macro names which differ either in data type or value. For example, SQLCHAR is one of the macros defined as follows:
//definition in Informix
#define SQLCHAR 0
//definition in TT
typedef unsigned char UCHAR;
typedef UCHAR SQLCHAR;
These components were compiled in a big project with the above two header file directories included by -I option. So errors occurred in the compilation process.
If the directory of Informix is included prior to that of TT, errors occur when compiling the component for TT, and vice versa.
The solution is to change the directory inclusion sequence according to which component is compiling.
Oracle is usually used as the phisycal database when TimesTen is working as in-memory database, because the data synchronization is very easy by using cache connect in such situation. But we had to use Informix as the physical database in some projects and we encountered problems just at the compilation stage.
In our product, the database access component which was based on esql includes the header file $INFORMIXDIR/incl/esql/sqltypes.h, and the component for accessing TimesTen was ODBC-oriented and includes the header file $TIMESTEN_HOME/include/sqltypes.h.
These two files are identical in file name but not in content. What's more, there are some identical macro names which differ either in data type or value. For example, SQLCHAR is one of the macros defined as follows:
//definition in Informix
#define SQLCHAR 0
//definition in TT
typedef unsigned char UCHAR;
typedef UCHAR SQLCHAR;
These components were compiled in a big project with the above two header file directories included by -I option. So errors occurred in the compilation process.
If the directory of Informix is included prior to that of TT, errors occur when compiling the component for TT, and vice versa.
The solution is to change the directory inclusion sequence according to which component is compiling.
A solution for conflict of structure loc_t in header files of vac compiler and informix esql on AIX
This article was originally posted in my csdn.net blog on 6 May 2009.
I encountered an error several days ago when a program based on informix esql was compiled on AIX platform. Error message:
"/informix/incl/esql/locator.h", line 124.7: 1540-0400 (S) "loc_t" has a conflicting declaration.
"/usr/include/sys/localedef31.h", line 195.3: 1540-0425 (I) "loc_t" is defined on line 195 of "/usr/include/sys/localedef31.h".
make: 1254-004 The error code from the last command is 1.
The version of Informix CliSDK is 2.81.FC2.AIX5L, and the same error occured when I compiled it using different vac compilers in version 6.0 and 7.0.
According to the error message, it's easy to locate the problem. I checked both two header files. Both files include definition of a structure loc_t with totally different content. The file localedef31.h should be used in customised program because it includes the format definition of currency, time, number and so on, while loc_t in locator.h is defined for accessing large object in Informix.
By consulting the Informix technician, I got to know there is a pre-compilation macro _H_LOCALEDEF to invalidate the defintion in vac compiler. And the definition in Informix esql header file can also be invalidated by introduction of pre-compilation macro IFX_DISABLE_LOC_T if the Informix CliSDK verion is 3.50 or higher.
As for our project, we have to access the large object and the definition of loc_t in Informix esql should be kept. Therefore I added -D_H_LOCALEDEF in makefile to resolve the conflict.
I encountered an error several days ago when a program based on informix esql was compiled on AIX platform. Error message:
"/informix/incl/esql/locator.h", line 124.7: 1540-0400 (S) "loc_t" has a conflicting declaration.
"/usr/include/sys/localedef31.h", line 195.3: 1540-0425 (I) "loc_t" is defined on line 195 of "/usr/include/sys/localedef31.h".
make: 1254-004 The error code from the last command is 1.
The version of Informix CliSDK is 2.81.FC2.AIX5L, and the same error occured when I compiled it using different vac compilers in version 6.0 and 7.0.
According to the error message, it's easy to locate the problem. I checked both two header files. Both files include definition of a structure loc_t with totally different content. The file localedef31.h should be used in customised program because it includes the format definition of currency, time, number and so on, while loc_t in locator.h is defined for accessing large object in Informix.
By consulting the Informix technician, I got to know there is a pre-compilation macro _H_LOCALEDEF to invalidate the defintion in vac compiler. And the definition in Informix esql header file can also be invalidated by introduction of pre-compilation macro IFX_DISABLE_LOC_T if the Informix CliSDK verion is 3.50 or higher.
As for our project, we have to access the large object and the definition of loc_t in Informix esql should be kept. Therefore I added -D_H_LOCALEDEF in makefile to resolve the conflict.
Monday, August 23, 2010
UnixODBC installation under IBM AIX
This article was originally posted in my csdn.net blog on 19 Mar 2009.
Download unixODBC-2.2.14.tar.gz from http://www.unixodbc.org/ first.
According to introduction in the document of http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0402walker/index.html, we can get the installation directory by using gzip -d and tar xvf.
Then issue the following command:
./configure --prefix=/home/unixodbc --disable-gui --disable-drivers CC=xlc_r CXX=xlC_r
But when I issued the command, an error stating xlc not found occured. By checking the PATH environment variable, I found the directory vacpp is missing because we didn't add this path in PATH environment variable for the root user.
Modified /etc/environment to add /usr/vacpp/bin into PATH environment variable and re-issued the above command. It's ok this time.
After the configure process finished, I checked the config.log and found some information like:
configure:23014: checking if platform is 64 bit
configure:23017: result: No
It seemed the installation program considered the platform is 32 bit. That must be for the reason we didn't set the OBJECT_MODE environment variable to 64 bit. So issued the command export OBJECT_MODE=64 and then start the configure process again. It's also ok now.
The second step was to make. It took a little bit time to make. The process in the beginning was very well, but the following error occurred when making the file SQLGetPrivateProfileString.c in the directory odbcinst:
source='SQLGetPrivateProfileString.c' object='SQLGetPrivateProfileString.lo' libtool=yes DEPDIR=.deps depmode=none /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile xlc_r -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"unixODBC\" -DVERSION=\"2.2.14\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LIBCRYPT=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_TIME_H=1 -DSIZEOF_LONG=8 -DPLATFORM64=1 -DHAVE_LONG_LONG=1 -DSIZEOF_LONG_INT=8 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOL=1 -DHAVE_ATOLL=1 -DHAVE_STRTOLL=1 -DHAVE_ENDPWENT=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_FTIME=1 -DHAVE_TIME=1 -DHAVE_LIBTHREAD=1 -D_REENTRANT=1 -DHAVE_LOCALTIME_R=1 -DHAVE_FTOK=1 -DHAVE_SEMGET=1 -DHAVE_SHMGET=1 -DHAVE_SEMOP=1 -DHAVE_SNPRINTF=1 -DNEED_SEMUNDO_UNION=1 -DCOLLECT_STATS=1 -DSTDC_HEADERS=1 -DHAVE_MALLOC_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PWD_H=1 -DHAVE_CRYPT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYNCH_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_LOCALE_H=1 -DHAVE_SYS_MALLOC_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_STDARG_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE_TIME_H=1 -DHAVE_DIRENT_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_PUTENV=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DHAVE_SETENV=1 -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1 -DUNIXODBC_SOURCE=1 -I. -I. -I../include -DSYSTEM_FILE_PATH=\"/ztebsn/unixodbc/etc\" -DDEFLIB_PATH=\"/ztebsn/unixodbc/lib\" -DSHLIBEXT=\".so\" -DUNIXODBC_SOURCE -I../libltdl -g -DENABLE_INI_CACHING -c -o SQLGetPrivateProfileString.lo SQLGetPrivateProfileString.c
xlc_r -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"unixODBC\" -DVERSION=\"2.2.14\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LIBCRYPT=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_TIME_H=1 -DSIZEOF_LONG=8 -DPLATFORM64=1 -DHAVE_LONG_LONG=1 -DSIZEOF_LONG_INT=8 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOL=1 -DHAVE_ATOLL=1 -DHAVE_STRTOLL=1 -DHAVE_ENDPWENT=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_FTIME=1 -DHAVE_TIME=1 -DHAVE_LIBTHREAD=1 -D_REENTRANT=1 -DHAVE_LOCALTIME_R=1 -DHAVE_FTOK=1 -DHAVE_SEMGET=1 -DHAVE_SHMGET=1 -DHAVE_SEMOP=1 -DHAVE_SNPRINTF=1 -DNEED_SEMUNDO_UNION=1 -DCOLLECT_STATS=1 -DSTDC_HEADERS=1 -DHAVE_MALLOC_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PWD_H=1 -DHAVE_CRYPT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYNCH_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_LOCALE_H=1 -DHAVE_SYS_MALLOC_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_STDARG_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE_TIME_H=1 -DHAVE_DIRENT_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_PUTENV=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DHAVE_SETENV=1 -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1 -DUNIXODBC_SOURCE=1 -I. -I. -I../include -DSYSTEM_FILE_PATH=\"/ztebsn/unixodbc/etc\" -DDEFLIB_PATH=\"/ztebsn/unixodbc/lib\" -DSHLIBEXT=\".so\" -DUNIXODBC_SOURCE -I../libltdl -g -DENABLE_INI_CACHING -c SQLGetPrivateProfileString.c -o SQLGetPrivateProfileString.o
"SQLGetPrivateProfileString.c", line 66.8: 1506-166 (S) Definition of function mutex_t requires parentheses.
"SQLGetPrivateProfileString.c", line 66.16: 1506-276 (S) Syntax error: possible missing '{'?
"SQLGetPrivateProfileString.c", line 70.24: 1506-045 (S) Undeclared identifier mutex.
"SQLGetPrivateProfileString.c", line 73.32: 1506-277 (S) Syntax error: possible missing ')' or ','?
"SQLGetPrivateProfileString.c", line 75.26: 1506-045 (S) Undeclared identifier mutex.
"SQLGetPrivateProfileString.c", line 261.23: 1506-045 (S) Undeclared identifier mutex_ini.
"SQLGetPrivateProfileString.c", line 281.23: 1506-045 (S) Undeclared identifier mutex_ini.
make: 1254-004 The error code from the last command is 1.
According to the error message, the complier can not find the definition of mutex_t. But it is defined in system header file /usr/include/synch.h, so this file sync.h should be directly or indirectly refered to by the file SQLGetPrivateProfileString.c.
Googled this error information I found some useful information in http://bbs.chinaunix.net/archiver/tid-1354992.html, this link presents a solution: copy $(SOURCEDIR)/DriverManager/drivermanager.h and __stats.h to the directory $(SOURCEDIR)/include. I did that but unfortunately it didn't work yet. The same error persisted.
After careful review for the file drivermanager.h, I found it does include synch.h if the pre-compile macro HAVE_SYNCH_H is defined and we can find -DHAVE_SYNCH_H=1 from the options in the compile command.
Then I checked SQLGetPrivateProfileString.c and found only two head files time.h and odbcinstext.h were included. I checked all the header files level by level but did not find synch.h or drivermanager.h. So I was convinced that the program should be modified so that the file synch.h can be refered to by file SQLGetPrivateProfileString.c. OK, let's do it.
Modify $(SOURCEDIR)/include/odbcinstext.h just like this:
add a new line
#include <drivermanager.h>
after the following line:
#include <odbcinst.h>
And then started to make again and no error occurred.
The last step was to install by issuing the command:
make install
Now the unixodbc is successfully installed.
Download unixODBC-2.2.14.tar.gz from http://www.unixodbc.org/ first.
According to introduction in the document of http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0402walker/index.html, we can get the installation directory by using gzip -d and tar xvf.
Then issue the following command:
./configure --prefix=/home/unixodbc --disable-gui --disable-drivers CC=xlc_r CXX=xlC_r
But when I issued the command, an error stating xlc not found occured. By checking the PATH environment variable, I found the directory vacpp is missing because we didn't add this path in PATH environment variable for the root user.
Modified /etc/environment to add /usr/vacpp/bin into PATH environment variable and re-issued the above command. It's ok this time.
After the configure process finished, I checked the config.log and found some information like:
configure:23014: checking if platform is 64 bit
configure:23017: result: No
It seemed the installation program considered the platform is 32 bit. That must be for the reason we didn't set the OBJECT_MODE environment variable to 64 bit. So issued the command export OBJECT_MODE=64 and then start the configure process again. It's also ok now.
The second step was to make. It took a little bit time to make. The process in the beginning was very well, but the following error occurred when making the file SQLGetPrivateProfileString.c in the directory odbcinst:
source='SQLGetPrivateProfileString.c' object='SQLGetPrivateProfileString.lo' libtool=yes DEPDIR=.deps depmode=none /bin/sh ../depcomp /bin/sh ../libtool --tag=CC --mode=compile xlc_r -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"unixODBC\" -DVERSION=\"2.2.14\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LIBCRYPT=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_TIME_H=1 -DSIZEOF_LONG=8 -DPLATFORM64=1 -DHAVE_LONG_LONG=1 -DSIZEOF_LONG_INT=8 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOL=1 -DHAVE_ATOLL=1 -DHAVE_STRTOLL=1 -DHAVE_ENDPWENT=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_FTIME=1 -DHAVE_TIME=1 -DHAVE_LIBTHREAD=1 -D_REENTRANT=1 -DHAVE_LOCALTIME_R=1 -DHAVE_FTOK=1 -DHAVE_SEMGET=1 -DHAVE_SHMGET=1 -DHAVE_SEMOP=1 -DHAVE_SNPRINTF=1 -DNEED_SEMUNDO_UNION=1 -DCOLLECT_STATS=1 -DSTDC_HEADERS=1 -DHAVE_MALLOC_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PWD_H=1 -DHAVE_CRYPT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYNCH_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_LOCALE_H=1 -DHAVE_SYS_MALLOC_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_STDARG_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE_TIME_H=1 -DHAVE_DIRENT_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_PUTENV=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DHAVE_SETENV=1 -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1 -DUNIXODBC_SOURCE=1 -I. -I. -I../include -DSYSTEM_FILE_PATH=\"/ztebsn/unixodbc/etc\" -DDEFLIB_PATH=\"/ztebsn/unixodbc/lib\" -DSHLIBEXT=\".so\" -DUNIXODBC_SOURCE -I../libltdl -g -DENABLE_INI_CACHING -c -o SQLGetPrivateProfileString.lo SQLGetPrivateProfileString.c
xlc_r -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"unixODBC\" -DVERSION=\"2.2.14\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LIBCRYPT=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_TIME_H=1 -DSIZEOF_LONG=8 -DPLATFORM64=1 -DHAVE_LONG_LONG=1 -DSIZEOF_LONG_INT=8 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOL=1 -DHAVE_ATOLL=1 -DHAVE_STRTOLL=1 -DHAVE_ENDPWENT=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_FTIME=1 -DHAVE_TIME=1 -DHAVE_LIBTHREAD=1 -D_REENTRANT=1 -DHAVE_LOCALTIME_R=1 -DHAVE_FTOK=1 -DHAVE_SEMGET=1 -DHAVE_SHMGET=1 -DHAVE_SEMOP=1 -DHAVE_SNPRINTF=1 -DNEED_SEMUNDO_UNION=1 -DCOLLECT_STATS=1 -DSTDC_HEADERS=1 -DHAVE_MALLOC_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PWD_H=1 -DHAVE_CRYPT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYNCH_H=1 -DHAVE_STRINGS_H=1 -DHAVE_STRING_H=1 -DHAVE_LOCALE_H=1 -DHAVE_SYS_MALLOC_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_SEM_H=1 -DHAVE_STDARG_H=1 -DHAVE_VARARGS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE_TIME_H=1 -DHAVE_DIRENT_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_PUTENV=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DHAVE_SETENV=1 -DHAVE_SETLOCALE=1 -DHAVE_STRCHR=1 -DUNIXODBC_SOURCE=1 -I. -I. -I../include -DSYSTEM_FILE_PATH=\"/ztebsn/unixodbc/etc\" -DDEFLIB_PATH=\"/ztebsn/unixodbc/lib\" -DSHLIBEXT=\".so\" -DUNIXODBC_SOURCE -I../libltdl -g -DENABLE_INI_CACHING -c SQLGetPrivateProfileString.c -o SQLGetPrivateProfileString.o
"SQLGetPrivateProfileString.c", line 66.8: 1506-166 (S) Definition of function mutex_t requires parentheses.
"SQLGetPrivateProfileString.c", line 66.16: 1506-276 (S) Syntax error: possible missing '{'?
"SQLGetPrivateProfileString.c", line 70.24: 1506-045 (S) Undeclared identifier mutex.
"SQLGetPrivateProfileString.c", line 73.32: 1506-277 (S) Syntax error: possible missing ')' or ','?
"SQLGetPrivateProfileString.c", line 75.26: 1506-045 (S) Undeclared identifier mutex.
"SQLGetPrivateProfileString.c", line 261.23: 1506-045 (S) Undeclared identifier mutex_ini.
"SQLGetPrivateProfileString.c", line 281.23: 1506-045 (S) Undeclared identifier mutex_ini.
make: 1254-004 The error code from the last command is 1.
According to the error message, the complier can not find the definition of mutex_t. But it is defined in system header file /usr/include/synch.h, so this file sync.h should be directly or indirectly refered to by the file SQLGetPrivateProfileString.c.
Googled this error information I found some useful information in http://bbs.chinaunix.net/archiver/tid-1354992.html, this link presents a solution: copy $(SOURCEDIR)/DriverManager/drivermanager.h and __stats.h to the directory $(SOURCEDIR)/include. I did that but unfortunately it didn't work yet. The same error persisted.
After careful review for the file drivermanager.h, I found it does include synch.h if the pre-compile macro HAVE_SYNCH_H is defined and we can find -DHAVE_SYNCH_H=1 from the options in the compile command.
Then I checked SQLGetPrivateProfileString.c and found only two head files time.h and odbcinstext.h were included. I checked all the header files level by level but did not find synch.h or drivermanager.h. So I was convinced that the program should be modified so that the file synch.h can be refered to by file SQLGetPrivateProfileString.c. OK, let's do it.
Modify $(SOURCEDIR)/include/odbcinstext.h just like this:
add a new line
#include <drivermanager.h>
after the following line:
#include <odbcinst.h>
And then started to make again and no error occurred.
The last step was to install by issuing the command:
make install
Now the unixodbc is successfully installed.
Differences of empty string between Oracle and Informix
This article was originally posted in my csdn.net blog on 16 Feb 2009.
The behaviors of empty string '' (no any characters between two single quotation marks) in Oracle and Informix are much different. Great attention should be paid to avoid making mistakes.
In Oracle:
SQL> select * from dual where '' is null;
DUMMY
-----
X
This indicates '' is the same with null. Therefore it can’t be compared with other values or itself:
SQL> select * from dual where ''='';
DUMMY
-----
SQL> select * from dual where ''!='';
DUMMY
-----
That is to say, the result of nvl(col1,'')='' is false even when col1 is null.
And we can also make a conclusion, the result is false when empty string '' is comapred with a string containing whitespaces ' '(whatever how many spaces):
SQL> select * from dual where ''=' ';
DUMMY
-----
Now let’s have a look in Informix:
select count(*) from systables where ''='';
367
This indicates empty string can be compared with others. Therefore it is not the same with null.
According to above result, we can be convinced that nvl(col1,'')='' is true when either col1 is null or col1=''.
But because is null or is no null can only be used for a column , we can’t write a where statement like where '' is null .
Because in Informix empty string can be compared with others, so let’s look what happens when we compare it with the string containing whitespaces:
select count(*) from systables where ''=' ';
367
That’s to say, empty string is the same with string containing whitespaces。
The behaviors of empty string '' (no any characters between two single quotation marks) in Oracle and Informix are much different. Great attention should be paid to avoid making mistakes.
In Oracle:
SQL> select * from dual where '' is null;
DUMMY
-----
X
This indicates '' is the same with null. Therefore it can’t be compared with other values or itself:
SQL> select * from dual where ''='';
DUMMY
-----
SQL> select * from dual where ''!='';
DUMMY
-----
That is to say, the result of nvl(col1,'')='' is false even when col1 is null.
And we can also make a conclusion, the result is false when empty string '' is comapred with a string containing whitespaces ' '(whatever how many spaces):
SQL> select * from dual where ''=' ';
DUMMY
-----
Now let’s have a look in Informix:
select count(*) from systables where ''='';
367
This indicates empty string can be compared with others. Therefore it is not the same with null.
According to above result, we can be convinced that nvl(col1,'')='' is true when either col1 is null or col1=''.
But because is null or is no null can only be used for a column , we can’t write a where statement like where '' is null .
Because in Informix empty string can be compared with others, so let’s look what happens when we compare it with the string containing whitespaces:
select count(*) from systables where ''=' ';
367
That’s to say, empty string is the same with string containing whitespaces。
An issue of errno in a multi-threaded environment under AIX
This article was originally posted in my csdn.net blog on 3 Feb,2009.
One of my team member encountered a problem about errno in a multi-threaded environment under AIX.
The program worked well before the introduction of a lower-level component which was mutil-threaded. But now it always exited during the startup process. After debugging we located the problem. The program called function mkdir during startup to create directory and then took corresponding actions according to the return value of mkdir and the value errno. If the return value was -1 and errno was EEXIST, the program thought the directory already existed. But actually the return value was -1 and errno was not EEXIST but 0 when the directory was in existence, so the program exited because it thought the directory could not be created.
The problem occurs just when the multi-threaded component is refered, therefore we can easily have clue to check where the problem is.
The definition of errno in errno.h is like the following:
#if defined(_THREAD_SAFE) || defined(_THREAD_SAFE_ERRNO)
/*
* Per thread errno is provided by the threads provider. Both the extern int
* and the per thread value must be maintained by the threads library.
*/
extern int *_Errno( void );
#define errno (*_Errno())
#else
extern int errno;
#endif /* _THREAD_SAFE || _THREAD_SAFE_ERRNO */
That is to say, errno can be used in multi-threaded environment if either THREAD_SAFE or _THREAD_SAFE_ERRNO is defined. The errno is not an integer but a functional pointer in such case.
But it was still confused because many modules worked well although THREAD_SAFE and _THREAD_SAFE_ERRNO were both not explicitly defined in our programs.
I remembered the pthread.h should be the first included header file in multi-threaded programming because the first code segment in pthread.h is just to define _THREAD_SAFE:
#ifndef _THREAD_SAFE
#define _THREAD_SAFE 1
#endif
Unfortunately many software engineers didn’t pay attention to this issue so that pthread.h is not at the first place in many source files. And it was too difficult for us to modify all files. So our solution was adding -D_THREAD_SAFE in makefile.
One of my team member encountered a problem about errno in a multi-threaded environment under AIX.
The program worked well before the introduction of a lower-level component which was mutil-threaded. But now it always exited during the startup process. After debugging we located the problem. The program called function mkdir during startup to create directory and then took corresponding actions according to the return value of mkdir and the value errno. If the return value was -1 and errno was EEXIST, the program thought the directory already existed. But actually the return value was -1 and errno was not EEXIST but 0 when the directory was in existence, so the program exited because it thought the directory could not be created.
The problem occurs just when the multi-threaded component is refered, therefore we can easily have clue to check where the problem is.
The definition of errno in errno.h is like the following:
#if defined(_THREAD_SAFE) || defined(_THREAD_SAFE_ERRNO)
/*
* Per thread errno is provided by the threads provider. Both the extern int
* and the per thread value must be maintained by the threads library.
*/
extern int *_Errno( void );
#define errno (*_Errno())
#else
extern int errno;
#endif /* _THREAD_SAFE || _THREAD_SAFE_ERRNO */
That is to say, errno can be used in multi-threaded environment if either THREAD_SAFE or _THREAD_SAFE_ERRNO is defined. The errno is not an integer but a functional pointer in such case.
But it was still confused because many modules worked well although THREAD_SAFE and _THREAD_SAFE_ERRNO were both not explicitly defined in our programs.
I remembered the pthread.h should be the first included header file in multi-threaded programming because the first code segment in pthread.h is just to define _THREAD_SAFE:
#ifndef _THREAD_SAFE
#define _THREAD_SAFE 1
#endif
Unfortunately many software engineers didn’t pay attention to this issue so that pthread.h is not at the first place in many source files. And it was too difficult for us to modify all files. So our solution was adding -D_THREAD_SAFE in makefile.
Sunday, August 22, 2010
An Error of S1000 GetNodeName When using TimesTen
This article was originally posted in my csdn.net blog on 2 Feb,2009.
Today I encountered a problem of not be able to connect TimesTen service on machine (B for short) from an HP-UX machine (A for short) in our test environment. But it’s ok originally.
First checked on B, there was no problem for local connection on B. And then checked the TimesTen connection configuration on A. It’s also ok. But when I tried to start ttisqlcs, such as:
$ttisqlcs ds1
Then an error as follows always occurred:
connect "DSN=ds1";
S1000: GetNodeName: nodename nor servname provided, or not known
The command failed.
When I inspected the error log file tterrors.log in the directory info, I found some information like ‘gethostbyname() failed’. So I thought it should be because of problem in host name resolution. Actually when I checked the file /etc/host, I did find something wrong. There were three IP addresses mapping with the host name of B. But after I removed two incorrect lines, the problem still persisted.
Later I tried to restart the TimesTen server( actually I thought this was not useful, but it just a try). Unfortunately there were no any Timesten services when issuing ttstatus command:
No TimesTen server running
No TimesTen webserver running
Checked tterrors.log again, I found the error information：
11:35:43.02 Warn: : 27070: TimesTen Daemon Release 7.0.4.0.0.tt70 started.
2009-02-02 11:35:43.11 Err : SRV: 27075: EventID=33 Server is exiting. gethostbyname() failed. ListenAddr: test1; System error: 1
At this moment, I got an error same with before if I issue command ‘ttisqlcs ds1’. There was no any difference because of no service of TimesTen. This indicated there was no relation with whether the local TimesTen services are running or not.
To confirm if there was a problem regarding with gethostbyname, I wrote a small program for test.
#include <stdio.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <arpa/nameser.h>
#include <resolv.h>
int main()
{
char sHostName[255];
memset(sHostName, 0x00, sizeof(sHostName));
if (-1 == gethostname(sHostName, sizeof(sHostName)))
{
printf("gethostname error\n");
return -1;
}
printf("hostname=%s\n",sHostName);
struct hostent *hp = gethostbyname(sHostName);
if (NULL == hp)
{
printf("herror=%d\n", h_errno);
herror("gethostbyname");
return -2;
}
return 0;
}
Save the file as a.c, then make and run it.
$cc -o a a.c
$./a
hostname=test1
herror=1
gethostbyname: Unknown host
The error was the same with that in tterrors.log file. System error code was 1, and host name could not be resolved.
Goolged error information "S1000: GetNodeName: nodename nor servname provided, or not known", there was no any result。And two articles returned when googling "S1000: GetNodeName". But there were no solutions in both articles.
And later I found it also failed to ping the host name. This indicated the information in /etc/hosts was not used for host name resolution. So I thought there should be some options in system configuration.
Started sam (or smh), selected the option of Networking and Communications, and then Network Services Configuration. There are many things. But I thought only following things were related:
DNS (BIND)
Hosts
NIS
Name Service Switch
For DNS configuration, it’s correctly configured company’s dns server. In Hosts section, the same with file /etc/hosts. And NIS was not in use。In the section of Name Service Switch there were also many things.
Type of First Second Third Fourth
Information Source Source Source Source
aliases /etc/aliases NIS
automount Local Files NIS
group /etc/group NIS
hosts DNS NIS /etc/hosts
netgroup NIS /etc/netgroup
networks NIS /etc/networks
passwd /etc/passwd NIS
protocols NIS /etc/protocols
publickey NIS /etc/publickey
rpc NIS /etc/rpc
services NIS /etc/services
ipnodes DNS /etc/hosts
Checked that line for hosts. Yes, it is. Because the search order for host name can be configured here.
Search Order:
1. [ DNS ->]
If Information is Not Found: [ Stop Searching ->]
If Source is Not Configured: [ Try Next Source ->]
If Source is Not Responding: [ Stop Searching ->]
2. [ NIS ->]
If Information is Not Found: [ Stop Searching ->]
If Source is Not Configured: [ Try Next Source ->]
3. [ /etc/hosts ->]
4. [ none ->]
Modified the option of Stop Searching to Try Next Source, and then restarted the machine. After about 10 minutes, the machine finished startup. It succeeded to ping the machine itself. And when issuing the command ttisqlcs ds1, it also successfully connected. So the problems was finally solved.
After that when I inspected /etc directory, I found nsswitch.conf was changed.
nsswitch.conf：
hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] nis [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] files
nsswitch.conf.old：
hosts: dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return] nis [NOTFOUND=return UNAVAIL=continue TRYAGAIN=continue] files
So actually we can modify the configuration file if we know that.
Today I encountered a problem of not be able to connect TimesTen service on machine (B for short) from an HP-UX machine (A for short) in our test environment. But it’s ok originally.
First checked on B, there was no problem for local connection on B. And then checked the TimesTen connection configuration on A. It’s also ok. But when I tried to start ttisqlcs, such as:
$ttisqlcs ds1
Then an error as follows always occurred:
connect "DSN=ds1";
S1000: GetNodeName: nodename nor servname provided, or not known
The command failed.
When I inspected the error log file tterrors.log in the directory info, I found some information like ‘gethostbyname() failed’. So I thought it should be because of problem in host name resolution. Actually when I checked the file /etc/host, I did find something wrong. There were three IP addresses mapping with the host name of B. But after I removed two incorrect lines, the problem still persisted.
Later I tried to restart the TimesTen server( actually I thought this was not useful, but it just a try). Unfortunately there were no any Timesten services when issuing ttstatus command:
No TimesTen server running
No TimesTen webserver running
Checked tterrors.log again, I found the error information：
11:35:43.02 Warn: : 27070: TimesTen Daemon Release 7.0.4.0.0.tt70 started.
2009-02-02 11:35:43.11 Err : SRV: 27075: EventID=33 Server is exiting. gethostbyname() failed. ListenAddr: test1; System error: 1
At this moment, I got an error same with before if I issue command ‘ttisqlcs ds1’. There was no any difference because of no service of TimesTen. This indicated there was no relation with whether the local TimesTen services are running or not.
To confirm if there was a problem regarding with gethostbyname, I wrote a small program for test.
#include <stdio.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <arpa/nameser.h>
#include <resolv.h>
int main()
{
char sHostName[255];
memset(sHostName, 0x00, sizeof(sHostName));
if (-1 == gethostname(sHostName, sizeof(sHostName)))
{
printf("gethostname error\n");
return -1;
}
printf("hostname=%s\n",sHostName);
struct hostent *hp = gethostbyname(sHostName);
if (NULL == hp)
{
printf("herror=%d\n", h_errno);
herror("gethostbyname");
return -2;
}
return 0;
}
Save the file as a.c, then make and run it.
$cc -o a a.c
$./a
hostname=test1
herror=1
gethostbyname: Unknown host
The error was the same with that in tterrors.log file. System error code was 1, and host name could not be resolved.
Goolged error information "S1000: GetNodeName: nodename nor servname provided, or not known", there was no any result。And two articles returned when googling "S1000: GetNodeName". But there were no solutions in both articles.
And later I found it also failed to ping the host name. This indicated the information in /etc/hosts was not used for host name resolution. So I thought there should be some options in system configuration.
Started sam (or smh), selected the option of Networking and Communications, and then Network Services Configuration. There are many things. But I thought only following things were related:
DNS (BIND)
Hosts
NIS
Name Service Switch
For DNS configuration, it’s correctly configured company’s dns server. In Hosts section, the same with file /etc/hosts. And NIS was not in use。In the section of Name Service Switch there were also many things.
Type of First Second Third Fourth
Information Source Source Source Source
aliases /etc/aliases NIS
automount Local Files NIS
group /etc/group NIS
hosts DNS NIS /etc/hosts
netgroup NIS /etc/netgroup
networks NIS /etc/networks
passwd /etc/passwd NIS
protocols NIS /etc/protocols
publickey NIS /etc/publickey
rpc NIS /etc/rpc
services NIS /etc/services
ipnodes DNS /etc/hosts
Checked that line for hosts. Yes, it is. Because the search order for host name can be configured here.
Search Order:
1. [ DNS ->]
If Information is Not Found: [ Stop Searching ->]
If Source is Not Configured: [ Try Next Source ->]
If Source is Not Responding: [ Stop Searching ->]
2. [ NIS ->]
If Information is Not Found: [ Stop Searching ->]
If Source is Not Configured: [ Try Next Source ->]
3. [ /etc/hosts ->]
4. [ none ->]
Modified the option of Stop Searching to Try Next Source, and then restarted the machine. After about 10 minutes, the machine finished startup. It succeeded to ping the machine itself. And when issuing the command ttisqlcs ds1, it also successfully connected. So the problems was finally solved.
After that when I inspected /etc directory, I found nsswitch.conf was changed.
nsswitch.conf：
hosts: dns [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] nis [NOTFOUND=continue UNAVAIL=continue TRYAGAIN=continue] files
nsswitch.conf.old：
hosts: dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return] nis [NOTFOUND=return UNAVAIL=continue TRYAGAIN=continue] files
So actually we can modify the configuration file if we know that.
Friday, August 20, 2010
TNS-12537 error because of inappropriate OS parameter on AIX
This article was originally published in my csdn.net blog on 29 Dec, 2008.
A problem was reported by a maintenance engineer this morning. An application program could not startup because error TNS-12537 occurred.
By checking oracle's listener.log, I found the detailed error message:
TNS-12518: TNS:listener could not hand off client connection
TNS-12549: TNS:operating system resource quota exceeded
TNS-12560: TNS:protocol adapter error
TNS-00519: Operating system resource quota exceeded
IBM/AIX RISC System/6000 Error: 11: Resource temporarily unavailable
It should be becasue of insufficiency of some system resources so that oracle couldn’t acquire more resources to set up the client connection. But the system memory was still several GB free, and the parameters shown by the command ‘ulimit –a’ were also large enough, and all file systems had enough free spaces. And then checked the kernel paramters of the system, there was a problem in the parameter maxuproc. Its value was the default value 128. It's too small for out project because this parameter denotes maximum number of processes allowed per user.
After communicating with the engineer, I knew that they deployed the application on a new machine without modification of maxuproc. Thus any clients could not connect Oracle server when the number of processes of Oracle user arrives 128. The problem was solved after increasing the value of maxuproc.
By the way:
To view the current value of maxuproc, use the lsattr command:
lsattr -E -l sys0 | grep maxuproc
and to change the value of maxuproc, use the chdev command by root user, for example:
chdev -l sys0 -a maxuproc=1024
is to set the value of maxuproc to 1024.
A problem was reported by a maintenance engineer this morning. An application program could not startup because error TNS-12537 occurred.
By checking oracle's listener.log, I found the detailed error message:
TNS-12518: TNS:listener could not hand off client connection
TNS-12549: TNS:operating system resource quota exceeded
TNS-12560: TNS:protocol adapter error
TNS-00519: Operating system resource quota exceeded
IBM/AIX RISC System/6000 Error: 11: Resource temporarily unavailable
It should be becasue of insufficiency of some system resources so that oracle couldn’t acquire more resources to set up the client connection. But the system memory was still several GB free, and the parameters shown by the command ‘ulimit –a’ were also large enough, and all file systems had enough free spaces. And then checked the kernel paramters of the system, there was a problem in the parameter maxuproc. Its value was the default value 128. It's too small for out project because this parameter denotes maximum number of processes allowed per user.
After communicating with the engineer, I knew that they deployed the application on a new machine without modification of maxuproc. Thus any clients could not connect Oracle server when the number of processes of Oracle user arrives 128. The problem was solved after increasing the value of maxuproc.
By the way:
To view the current value of maxuproc, use the lsattr command:
lsattr -E -l sys0 | grep maxuproc
and to change the value of maxuproc, use the chdev command by root user, for example:
chdev -l sys0 -a maxuproc=1024
is to set the value of maxuproc to 1024.
The format of default value for datetime field in Informix
This article was published in my csdn.net blog on 26 Dec, 2008.
Recently there was an application involved in Informix database not insert value in a nullable column of the type ‘DATETIME YEAR TO SECOND’, but that column would be used by other applications. Therefore, I decided to use the default scheme provided by database.
It’s very easy to add a constraint of default value for column of type DATE in oracle, just use ‘default sysdate’ in the ‘alter table … modify …’ statement. Unfortunately, when I used the ‘default current’ in the alter table statement, an error ‘Invalid default value for column/variable’ occurred.
After reading the manual of Informix SQL, I found it should be like ‘default current year to second’.
A case for coredump under HP-UX B.11.31 U ia64 + oracle 10.2
This article was originally posted in my csdn.net blog on 11 Dec, 2008.
A pro*c based application could run correctly under AIX and either oracle9i or oracle 10g, and it was also ok for HPUX and oracle9i. But it always encountered coredump when connecting to the database for HPUX and oracle10g.
Information in core file was as follows:
Program received signal SIGBUS, Bus error
si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3.
warning: Load module /oracle/product/102/lib/libclntsh.so.10.1 has been stripped.
Debugging information is not available.
warning: Load module /oracle/product/102/lib/libnnz10.so has been stripped.
Debugging information is not available.
#0 0xc0000000004c6dd0:0 in getsockopt+0xb0 ()
from /usr/lib/hpux64/libxnet.so.1
(gdb) where
#0 0xc0000000004c6dd0:0 in getsockopt+0xb0 ()
from /usr/lib/hpux64/libxnet.so.1
#1 0xc000000008ea0440:0 in+ 0x750 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#2 0xc000000008c3d420:0 in ntconn+0x1e0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#3 0xc000000008c44940:0 in+ 0x1a0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#4 0xc000000008c3f980:0 in ntevpwi+0xc0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#5 0xc000000008c40150:0 in ntgbuini+0x210 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#6 0xc000000008c0f890:0 in nsgblini+0x590 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#7 0xc000000008c4b4c0:0 in niotns+0x6c0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#8 0xc000000008d47de0:0 in nigcall+0xa0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#9 0xc000000009456510:0 in+ 0x750 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#10 0xc000000008683a20:0 in kpuadef+0x80 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#11 0xc0000000088b22e0:0 in upiini+0x420 ()
---Typeto continue, or q to quit---
from /oracle/product/102/lib/libclntsh.so.10.1
#12 0xc000000008871280:0 in upiah0+0x80 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#13 0xc000000008682790:0 in kpuatch+0x800 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#14 0xc0000000088b8a20:0 in OCIServerAttach+0xe0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#15 0xc000000008608350:0 in+ 0x2f0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#16 0xc00000000860a500:0 in sqllam+0x200 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#17 0xc00000000861cad0:0 in sqllo3t+0x390 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#18 0xc000000008618730:0 in+ 0x350 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#19 0xc00000000861bf70:0 in sqlexp+0x18b0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#20 0xc00000000860d420:0 in+ 0xb30 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#21 0xc00000000860e870:0 in sqlcxt+0x110 ()
from /oracle/product/102/lib/libclntsh.so.10.1
Googled BUS_ADRALN - Invalid address alignment but no helpful clue was found.
So I checked getsockopt's definition. There were three prototypes found from the manual:
#include <sys/socket.h>
int getsockopt(
int s,
int level,
int optname,
void *optval,
int *optlen
);
UNIX 03 Only (X/Open Sockets)
int getsockopt(
int s,
int level,
int optname,
void *__restrict optval,
socklen_t *__restrict optlen
);
Obsolescent UNIX 95 Only (X/Open Sockets)
int getsockopt(
int s,
int level,
int optname,
void *optval,
size_t *optlen
);
The program used getsockopt in /usr/lib/hpux64/libxnet.so.1, which could be ascertained from the core file information. The makefile included the option -lxnet and libxnet.so was just a symbol file of libxnet.so.1.
I infered there was certain problem when this library file was linked.
After that I found getsockopt in libc.a by using the command nm libc.a, therefore I decided to remove the option -lxnet from the makefile. And I'm so lucky that the problem was sovled.
A pro*c based application could run correctly under AIX and either oracle9i or oracle 10g, and it was also ok for HPUX and oracle9i. But it always encountered coredump when connecting to the database for HPUX and oracle10g.
Information in core file was as follows:
Program received signal SIGBUS, Bus error
si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3.
warning: Load module /oracle/product/102/lib/libclntsh.so.10.1 has been stripped.
Debugging information is not available.
warning: Load module /oracle/product/102/lib/libnnz10.so has been stripped.
Debugging information is not available.
#0 0xc0000000004c6dd0:0 in getsockopt+0xb0 ()
from /usr/lib/hpux64/libxnet.so.1
(gdb) where
#0 0xc0000000004c6dd0:0 in getsockopt+0xb0 ()
from /usr/lib/hpux64/libxnet.so.1
#1 0xc000000008ea0440:0 in
from /oracle/product/102/lib/libclntsh.so.10.1
#2 0xc000000008c3d420:0 in ntconn+0x1e0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#3 0xc000000008c44940:0 in
from /oracle/product/102/lib/libclntsh.so.10.1
#4 0xc000000008c3f980:0 in ntevpwi+0xc0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#5 0xc000000008c40150:0 in ntgbuini+0x210 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#6 0xc000000008c0f890:0 in nsgblini+0x590 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#7 0xc000000008c4b4c0:0 in niotns+0x6c0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#8 0xc000000008d47de0:0 in nigcall+0xa0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#9 0xc000000009456510:0 in
from /oracle/product/102/lib/libclntsh.so.10.1
#10 0xc000000008683a20:0 in kpuadef+0x80 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#11 0xc0000000088b22e0:0 in upiini+0x420 ()
---Type
from /oracle/product/102/lib/libclntsh.so.10.1
#12 0xc000000008871280:0 in upiah0+0x80 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#13 0xc000000008682790:0 in kpuatch+0x800 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#14 0xc0000000088b8a20:0 in OCIServerAttach+0xe0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#15 0xc000000008608350:0 in
from /oracle/product/102/lib/libclntsh.so.10.1
#16 0xc00000000860a500:0 in sqllam+0x200 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#17 0xc00000000861cad0:0 in sqllo3t+0x390 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#18 0xc000000008618730:0 in
from /oracle/product/102/lib/libclntsh.so.10.1
#19 0xc00000000861bf70:0 in sqlexp+0x18b0 ()
from /oracle/product/102/lib/libclntsh.so.10.1
#20 0xc00000000860d420:0 in
from /oracle/product/102/lib/libclntsh.so.10.1
#21 0xc00000000860e870:0 in sqlcxt+0x110 ()
from /oracle/product/102/lib/libclntsh.so.10.1
Googled BUS_ADRALN - Invalid address alignment but no helpful clue was found.
So I checked getsockopt's definition. There were three prototypes found from the manual:
#include <sys/socket.h>
int getsockopt(
int s,
int level,
int optname,
void *optval,
int *optlen
);
UNIX 03 Only (X/Open Sockets)
int getsockopt(
int s,
int level,
int optname,
void *__restrict optval,
socklen_t *__restrict optlen
);
Obsolescent UNIX 95 Only (X/Open Sockets)
int getsockopt(
int s,
int level,
int optname,
void *optval,
size_t *optlen
);
The program used getsockopt in /usr/lib/hpux64/libxnet.so.1, which could be ascertained from the core file information. The makefile included the option -lxnet and libxnet.so was just a symbol file of libxnet.so.1.
I infered there was certain problem when this library file was linked.
After that I found getsockopt in libc.a by using the command nm libc.a, therefore I decided to remove the option -lxnet from the makefile. And I'm so lucky that the problem was sovled.
Subscribe to:
Posts (Atom)