Thnx for the reply.
----
As usual, I can't even guess what you are trying to ask or tell with some of the code you quoted
Code: wlfs_frame_rsp( (uint16*)lfs_msg_ptr, length )
----
// if i do a UP from the place where the debugger is complaining about the code, phch_last->next = phch_iter->next; it takes me to wlfs_frame_rsp( (uint16*)lfs_msg_ptr, length ) i modified this uint16* to uint*

Kindly refer to 11th post for data structure and code details, in my 14th post though even i feel its not very clear but thatz the only significant output which was available after comparing the 32 bit passing log with the 64 bit failing log.

If you want to continue posting code in forums, you should learn how to use code tags to make the code readable.
//Thanks for the suggestion, i will take care of this from now onwards.

-----------
//As per the discussion that was one of the pointers i got to proceed further to fix this issue. Since the uint16* is used and like you mentioned (uint*) in that code are casts of a type that is likely to be non portable when switching between a 32 bit and 64 bit architecture. So any construct like that might be the bug that is causing problem. I still want to understand little more on this as somewhere this can be the cause of problem.

Regards
Sahil

In the 11th post you have a lot of declarations and executable code. But obviously a lot of executable code in that function is missing from there. Otherwise, the executable code you showed uses all uninitialized variables and performs meaningless functions.

Also, those declarations do not include the data structures. For example you include the declarations of several pointers to a data structure named WCDSP_PHCH_STATUS_STR but you don't include the definition of that data structure.

WHY?

That seems to be a completely random change. You aren't going to fix bugs by making random changes. Random changes will just add more bugs.

Quote:
i modified this uint16* to uint*

Yes right this was one of the random changes to check on the basis of something i read in some other post.
I am not convinced with this and i feel there is something certainly to do with data type here which is causing the problem. I didnt understand the behaviour of uint16* here , and what sud be the ideal repleacement if needed for 64bit data type.
Like you mentioned (uint*) in that code are casts of a type that is likely to be non portable when switching between a 32 bit and 64 bit architecture.

-------
But obviously a lot of executable code in that function is missing from there. Otherwise, the executable code you showed uses all uninitialized variables and performs meaningless functions.
-------
ya i could have added some more relevant info.......just that wasnt sure how much code sud i put as its huge and involves lotts of files with thousands of lines of code. I just posted the code of the area where debugger was complaing

Hi,

I build the testcase on 32 bit machine and executed the same on 64 bit machine. Its passing successfully. Seems like compilation on 64 bit is causing the problem and some data type compatibility issues is there.

-Thnx!
sahil

phch_last->next = phch_iter->next;
phch_last = phch_iter;
free(phch_iter);

phch_iter->next
struct_WCDSP_PHCD_STATUS_STR *) 0*0

phch_last its (WCDSP_PHCH_STATUS_STR *) 0*20
It's not correct for a pointer in x86_64 to contain the value 0x20.

value assigned as Null.
-------
WCDSP_PHCH_STATUS_STR *phch_iter;
WCDSP_PHCH_STATUS_STR *phch_last = NULL ;
WCDSP_TRCH_STATUS_STR *trch_iter;
WCDSP_TRCH_STATUS_STR *trch_tmp1;
-------


Problem resolved with this fix.!!

------

Thanks Johnsfine for all the help .