DevOps, CI/CD and Automation

My application core dumps sporadically in the strftime function. My appliaction was working fine for a long time. During the last move i added some code fragments using tzset function and i am doubting whether this has anything to do with the dumps in strftime.
Machine Info : SunOS 5.6 Generic_105181-33 sun4u sparc SUNW,Ultra-Enterprise machines

Can anyone guide me to the way for solving this problem Here is my code where the dump happens.

void ChkPerCookie(SESSION Session, char pcookie, char UAgent, char SessionAction, char *LoginAction)
{
time_t now=0;
struct tm* tmtime;
char ntime[64];
char LogMsg[256];
char TimeBuf[64];
*LogMsg = 0;
now = time(0);
tmtime = localtime(&now);
strftime(TimeBuf, 64, "%m/%d/%Y %H:%M:%S", tmtime); // dumps core here
...

And here is the stack trace -

(gdb) bt
#0 0xef5d0030 in strcat ()
#1 0xef5d44dc in _tzload ()
#2 0xef5d3224 in ltzsetu ()
#3 0xef5d2df8 in mktime ()
#4 0xef5ff584 in strftime ()
#5 0xaa4f4 in ChkPerCookie (Session=Cannot access memory at address 0x6f6e65ad.
) at ../src/PRO_WebMsgProcs.c:1271
Cannot access memory at address 0x6f6e65a1.

I had a look at the input registers. I find that the values passed to strftime are intact. Here is the contents of the input registers-

(gdb) info registers
i0 0xefffc200 -268451328 // address of TimeBuf where the formatted date string will be copied
i1 0x40 64 // Length of buffer TimeBuf
i2 0x6c85e8 7112168 // format string passed to strftime ( 0x6c85e8 <.LI117+8888>: "%m/%d/%Y %H:%M:%S" )
i3 0xef62bc5c -278741924 // tm time structure
Contents of the tm structure as shown by gdb
tmtime->tm_sec = 54;
tmtime->tm_min = 27;
tmtime->tm_hour= 11;
tmtime->tm_mday= 16;
tmtime->tm_mon = 3;
tmtime->tm_year= 103;
tmtime->tm_wday= 3;
tmtime->tm_yday= 105;
tmtime->tm_isdst=1;

I see that the strcat called from _tzload is trying to cat the string "zoneinfo" endlessly till it goes out of the segment boundary and core dumps due to SEGV.

(gdb) x/s 0xefffbbc8
0xefffbbc8: "/usr/share/lib/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zone
info/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zoneinfo/zonei
"...
Can anybody let me know where the problem is.
Thanks in advance.