SEO

We have an application that runs under Linux, solaris. The Application
was developed in C++ under linux, it supports both Oracle and Informix
database.

For database connectivity in oracle it uses OTL (Oracle template
library) and for informix it uses ESQL

In all the platforms we use GNU C/C++ compiler for building the
executable( Version >= 3.3.2)

Now we are trying to port this application to IBM AIX 5.2 machine (64
bit machine), it compiles fine, when we run the server for Oracle it
works fine but when we run the same server for informix it crashes
(Signal 11, Segmentation fault).

The crash happens in various places, some time it happens when we
allocate memory for an object using new system call.

Following is the error Output detected by GDB:
Location: When program try to create informix data adaptor (using
new) for second time.
Error with Thread:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1]
0x09000000002d894c in _usched_swtch ()
from /usr/lib/libpthreads.a(shr_xpg5_64.o)
(gdb) where
#0 0x09000000002d894c in _usched_swtch ()
from /usr/lib/libpthreads.a(shr_xpg5_64.o)
#1 0x09000000002d919c in _event_wait ()
from /usr/lib/libpthreads.a(shr_xpg5_64.o)
#2 0x09000000002e4d54 in _cond_wait_local ()
from /usr/lib/libpthreads.a(shr_xpg5_64.o)
#3 0x09000000002e51b4 in _cond_wait ()
from /usr/lib/libpthreads.a(shr_xpg5_64.o)
#4 0x09000000002d4b50 in pthread_join ()
from /usr/lib/libpthreads.a(shr_xpg5_64.o)
#5 0x00000001000b8074 in CServerThread::CreateThread
(this=<incomplete type>)
at /mega/ETL/ETLServer/Server_ORG/Source/ETLUtilities/ETLCommunicationInterf
ace/ETLThread/ETLUtilitiesThread.cpp:282
#6 0x00000001000015dc in main (argc=271486416, argv=<incomplete
type>)
at /usr/local/include/c++/3.3.2/bits/stl_iterator.h:602


sometime it happens when application try to connect with informix
database using ESQL connect

Following is the error Output detected by GDB:
Location: When program try to connect to informix database using
informix data adaptor
Error with Thread:
Program received signal SIGSEGV, Segmentation fault.
0x0900000000043170 in malloc_y () from /usr/lib/libc.a(shr_64.o)
(gdb) where
#0 0x0900000000043170 in malloc_y () from /usr/lib/libc.a(shr_64.o)
#1 0x090000000004293c in malloc_y_heap () from
/usr/lib/libc.a(shr_64.o)
#2 0x0000000100241990 in ifx_alloc_conn_user ()
#3 0x000000010012efe8 in CEsqlDataAdaptor::EsqlConnect (
this=<incomplete type>, ai_strUserName=0x1103a78a8 "megaadm",
ai_strPassword=0x1103a7350 "megaplus",
ai_strConnectString=0x1103a5ca8 "merkur_net",
ai_strDatabaseName=0x1103a5cf8 "INFSRCREP301") at
ETLEsqlDataAdaptor.ec:271
#4 0x000000010012625c in CInformixDataAdaptor::Connect
(this=0x1103f0430,
ai_strUserName=0x1103a78a8 "megaadm",
ai_strPassword=0x1103a7350 "megaplus",
ai_strConnectString=0x1103a5ca8 "merkur_net",
ai_strDatabaseName=0x1103a5cf8 "INFSRCREP301")
at ETLInformixDataAdaptor.cpp:279


we checked the memory allocation in our program, it is fine (it runs
in Linux, Solaris, SCO and Windows), we also used GNU Malloc library
for compiling the application, still crashs at the same positions

Please let me know if anyone have a clue how to solve this problem.

Thanks in advance.

thanvir@gmail.com (Thanvir) writes:

> The crash happens in various places, some time it happens when we
> allocate memory for an object using new system call.

Any crash in malloc() indicates (with 99.9% probability) heap
corruption, e.g. double-free, free unallocated, etc.

The crash on HP-UX which you described in comp.sys.hp.hpux likely
has the same root cause.

> we checked the memory allocation in our program, it is fine

No, it isn't.

> (it runs in Linux, Solaris, SCO and Windows),

You got lucky. It is not at all uncommon to uncover heap corruption
bugs when porting from one platform to another.

Another thing to note is that your 2 crashing platforms are both
64-bit. Does your app run fine on Solaris and Linux in 64-bit mode?
If not, you may have 64-bit bug (such as storing a pointer into
an int).

> we also used GNU Malloc library

Did you run your app with MALLOC_CHECK_=2 (on Linux)?

> Please let me know if anyone have a clue how to solve this problem.

There are free and commercial tools that can help you locate the
problem: ElectricFence, dmalloc, ccmalloc, Valgrind (Linux/x86 only),
Purify, Insure++.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul Pluzhnikov wrote:

> thanvir@gmail.com (Thanvir) writes:
>
>
>>The crash happens in various places, some time it happens when we
>>allocate memory for an object using new system call.
>
>
> Any crash in malloc() indicates (with 99.9% probability) heap
> corruption, e.g. double-free, free unallocated, etc.
>
> The crash on HP-UX which you described in comp.sys.hp.hpux likely
> has the same root cause.
>
>
>>we checked the memory allocation in our program, it is fine
>
>
> No, it isn't.
>
>
>>(it runs in Linux, Solaris, SCO and Windows),
>
>
> You got lucky. It is not at all uncommon to uncover heap corruption
> bugs when porting from one platform to another.
>
> Another thing to note is that your 2 crashing platforms are both
> 64-bit. Does your app run fine on Solaris and Linux in 64-bit mode?
> If not, you may have 64-bit bug (such as storing a pointer into
> an int).
>
>
>>we also used GNU Malloc library
>
>
> Did you run your app with MALLOC_CHECK_=2 (on Linux)?
>
>
>>Please let me know if anyone have a clue how to solve this problem.
>
>
> There are free and commercial tools that can help you locate the
> problem: ElectricFence, dmalloc, ccmalloc, Valgrind (Linux/x86 only),
> Purify, Insure++.
>
> Cheers,

You may want to look at the MALLOCTYPE=debug and MALLOCDEBUG environment
variables on AIX. See pubs URL
http://publibn.boulder.ibm.com/doc_l...bug_malloc.htm
for a description of these variables.

Jim Lahue