You are not logged in.
We are working on a legacy code base which we compile on a 32 bit linux machine using latest g++ compiler. As the size of input data to binary is increasing now a days, the binary runs slower. So hence we are now migrating the code the 64 Bit. The code gets compiled properly but crashes (the same code which runs properly on 32 Bit). The debug results shows that it is crashing while accessing some static objects. Assuming that this would be due to some memory corruption in Data Segment, we tried to use valgrind with memcheck option, but found it insufficient to trace the root cause for memory corruption. Could anyone please suggest some new tools or methods to fix this issue or if valgrind itself can be used in a better way.
Last edited by Dheerendra (2016-07-27 09:35 AM)
Valgrind would normally be my first recommendation, but if you've already tried it without it being helpful, I'm not sure of a better option... Have you already tried it with one or more "-v"s to make it more verbose? If that didn't help, I'd probably just resort to old-school tactics like riddling the code with debugging code at various places of interest...
Thanks for the reply RobSeace. Tried it with -v option but still couldn't identify the exact part of the code which is corrupting the memory.
When I run valgrind, it complains about "Invalid read of size 4" where the code is exactly crashing (while accessing some static objects members). But we aren't getting any other complains prior to this where it says something like "Invalid write".
Some suggestions on this would really be helpfull.
It sounds like you've got some kind of pointers in these static objects? Maybe something is setting them to bad values... That wouldn't trip a valgrind complaint, because no memory corruption would be taking place, just normal setting of a pointer to some value... I'd look for anything that sets those problematic pointers you're crashing when trying to follow, and closely examine what they're doing... Maybe they're doing some pointer arithmetic, but casting things to 32-bit int and then back to pointer, and that's going to be problematic with 64-bit pointers?
Hey hi RobSeace, We thought of using gcc with -mx32 (which compiles long and pointers in 32 bit styles). We also need to build all the dependent libraries with the same option right, including system libraries. And if we are able to do that, are there any other run time errors expected in this approach?
Could you please share your comments?
I wouldn't do that... If you are going to do that, might as well stick with regular 32-bit code, as there's not really any gain... 64-bit longs and pointers aren't a problem to be worked around, but a desirable feature! You just need to figure out where your code is doing something wrong with them...
Hey hi all, We were able to resolve the crash!!!!
Reason for memory corruption:
Improper packing of structures using #pragma pack(4) in some header files. And some #pragma packs were not removed correctly after using.
Hence the cpp files which included these header files created all its data in packed format and some files which didn't include these file created data in normal format.
Hence the code might had been crashed when the normal file(un packed one) tried to access packed data structure... (due to difference in sizes).
We started with the divide and conquer kind of approach. That is we tried to build the code module-wise, including the necessary dependencies.
Hence we could narrow down the issue to get the corrupted code.
@RobSeace, Thanks for your help!!
Last edited by Dheerendra (2016-08-02 09:08 AM)