Core dump in the application

Applications Programming
1

Hi,
I am facing an issue with the core dump, i am not exactly able to figure out why and where i am getting it and how should i resolve it
Please find the dbx run on the core
reading symbolic information ...
Segmentation fault in realloc_y at 0x900000000046980 ($t1)
0x900000000046980 (realloc_y+0x4fc) 90100000 stw r0,0x0(r16)
(dbx) where
realloc_y(??, ??, ??) at 0x900000000046980
realloc_y_heap(??, ??) at 0x9000000000475a0
sqlrlc(??, ??, ??, ??) at 0x800000000d6c764
sqlcopydfn(??, ??, ??, ??, ??) at 0x800000000d86250
sqlrdf(??, ??, ??, ??, ??, ??) at 0x800000000d865cc
sqlatm(??, ??, ??, ??, ??, ??, ??) at 0x800000000d88d74
sqlnst(??, ??, ??) at 0x800000000d82574
sqlcmex(??, ??, ??, ??, ??) at 0x800000000d74d18
sqlcxt(??, ??, ??, ??) at 0x800000000d74374
unnamed block $b297, line 7956 in "b_pc.c"
SelectSequenceActivity(??), line 7956 in "b_pc.c"
ProcessTravelDealRecord(pTravelDealRecord = 0x000000010007c290), line 5602 in "test.c"
ParseMainSec(??), line 818 in "a.c"
ParseBatch(??), line 192 in "a.c"
ProcessBatch(pBatch = 0x09001000a0003898), line 3198 in "test.c"
main(argc = 0, argv = (nil)), line 1108 in "test.c"

Please Advice
Regards
mad_man12

2

Are you malloc'ing a large block of memory and then realloc'ing it to reduce or increase the size of this block of memory?

Can you show us the source for b_pc.c?

What OS are you on?

3

Your heap is almost certainly being corrupted.

Most likely causes are writing too many bytes into a malloc'd/realloc'd/new'd/etc block, freeing a block multiple times, accessing a block after it's been freed.

Your best approach is to use some sort of memory debug/corruption detection tool. The best tool I know of is something like IBM's (originally Rational) Purify. IIRC, "realloc_y" is an indication you're running on AIX. I don't know for certain the Purify is available for AIX, but it probably is, and it'd probably be a good test case for a demo of Purify to see what it can do.

There are also others tools that provide similar memory-checking capabilities.

4

Thanks for the responses,
I have looked in the code but couldn't figure out the problem area
I am not having rational purifier.
Murphy i am attaching the file a_pc.c

Is there somewhere you see the bug is.

Regards

5

These sure look questionable to me:

    vBase_Prod_Old[strlen(vBase_Prod_Old)] = '\0'; 
    vbase_prod[strlen(vbase_prod)] = '\0';

Those were the only variables using of heap memory I noted in that code, and that code snippet tells me someone's trying everything they can think of to patch over the problem. I'd make sure every possible use of strcpy() or similar is changed to an equivalent strncpy() to make sure the buffers those variables point to aren't overwritten.

I'd probably also convert them to stack variables:

    #define PROD_STR_LEN 32
       .
       .
       .
    char vbase_prod[ PROD_STR_LEN ];
       .
       .
       .
    strncpy( vbase_prod, some_source_str, sizeof( vbase_prod ) - 1 );
    vbase_prod[ sizeof( vbase_prod ) - 1 ] = '\0';
       .
       .
       .

There's a good chance that even doing all that won't work - I didn't see anything in that code that ensures the heap is being corrupted in the code you provided - it could be getting corrupted somewhere else in your application. ANYWHERE else in your application.

So, if the problem persists after that, go to your boss and explain to him that he can keep paying you and however many others are working on this problem $X per hour, or he can just pay for a real memory checking tool. Guess which one is going to be cheaper.

Look at it this way: would you expect someone to fix a car using only two screwdrivers and a pair of pliers? There are tools that make jobs easier, faster, and cheaper. A LOT easier, faster, and cheaper.

6

Hi Achenle,

I tried the below code changes and I am trying more on it to see if there is anywhere else the cause of the problem.

I am looking at the possible use of MALLOCDEBUG

Thanks a lot for your inputs and yes i am surely going to reply my BOSS as mentioned by you:-)