aC++ compiler versions

[aparna challagulla]

Hi,

We have two applications running on two different N class server clusters on hp-ux 11i.
We are experencing some problems when application1 is trying to send data to application2 in the past two weeks. the data is not reflected on the other application (sometimes not always ) though it is being stored in the database which is Oracle 9i on both the servers.We also have MQSeries as the middleware.
The developers think that it is due to mismatch between the version of aC++ compilers on the servers.
B3913DB C.03.30.02 HP aC++ Compiler (S800)

B3913DB C.03.33.01 HP aC++ Compiler (S800)

application1 is a new one which went into production in aug so they are not sure whether it is a bug or really a compiler problem.

frankly speaking i feel that it is a problem with their code( but i cannot say that to my boss now, can i? :)

so here i am !!
can someone pl tell me which is the newer version of the both.
has anyone faced any problems due to compiler versions.
thanks in advance.
pl help me
aparna

[Zeev Schultz]

To be honest its a bit hard to see a problem when you have no clear signs of one.Some (I think 30-40%) of compilers' bugs usually end with application dumping core.If this is the case you can at least see the stack trace with debugger (assume gdb).Another 30% percent of problems may come from compatibility issues with standards (ansi etc).

Anyway , here's the revisions' history for aC++,can check the release information for 03.30 vs 03.33 :

http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1743,00.html

Zeev

[Stefan Farrelly]

B3913DB C.03.33.01 HP aC++ Compiler (S800)
is the newer version.

As for finding out the differences they could be minor or could be major, certainly possible the version difference could be causing you problems. The version difference is quite big.

Why not upgrade the 30.02 version to the later 33.02 version to see if it fixes your problem.

[Umapathy S]

Aparna,
What does the system tests reveal before going into production? Did they work correctly?

If you have upgraded the compilers in between the current and previous releases of the application, then you can have a say for the compiler problem.

I think you are not getting the messages into application2 from the MQSeries. May be it is a problem in MQSeries side or the Queue exit program.

My suggestions.
HTH,
Umapathy

[aparna challagulla]

hi Zeev,

The applictaion does not dump any core. The code just hangs while trying to do some dynamic memory allocation.
Thanks for the link.

hi Stefan,

We will upgrade to 33.02 after the days activities are over and see if it solves the issue.

hi Umapathy,

The application worked fine during testing. no problem at all.
We did not do any upgradation on the compilers.
The MQSeries does not have any errors but i will check again just in case i find something.

Thanks a lot for your suggestions.

have fun
aparna

[Mike Stroyan]

A hang during memory allocation is often a problem with the application code writing past the end of an allocated memory area. That can lead to a crash or a cpu-bound loop in later memory allocations when the damaged data structure is used. There was a performance improvement in aCC 3.33 runtime that could expose a latent application problem. As noted in the following extract from the release notes, the default is not to use the small block allocator. That causes a different amount of alignment padding beyond a requested memory size. It could expose problems where bad code had been writing into the padding bytes. That same code could now be writing into important data structures.
You could try a quick experiment with using _M_SBA_OPTS to change the use of small block allocator and the amount of padding. You could use wdb's memory check tool to look for writes before or after block bounds.

=============================================

o Small Block Allocator for malloc

The aC++ runtime now automatically enables malloc's Small
Block Allocator (SBA) after the aCC runtime patch and libc patch
appropriate for your system are installed. (See the Required
Patches section above.) This improves heap performance.
See malloc(3) and mallopt(3).

The default values are:
M_MXFAST = 512 bytes
M_NLBLKS = 100
M_GRAIN = 8 bytes

If you want to change the defaults, the environment variable _M_SBA_OPTS
can be used. The format is:
export _M_SBA_OPTS=::

If your existing application is already calling mallopt, then mallopt
will likely return an error because libCsup will have already called
mallopt and allocated a small block by the time the application calls
mallopt.

If the above defaults are acceptable or you are already using
_M_SBA_OPTS then the error should just be ignored. If the defaults
would degrade performance, then either set _M_SBA_OPTS with the values
used by the application or you can disable this new feature by using the
following:
export _M_SBA_OPTS=0:0:0

Applications with latent memory leaks may fail. If the application
allocates a block that is too small while SBA is disabled, the block
may be padded such that a overrun of the end of the allocated block
might not cause a failure. But with SBA enabled, the next contiguous
bytes may have been used for control information and an overrun
would corrupt the heap and cause various aborts.