On Mon, May 23, 2011 at 8:29 PM, Fawad Lateef <fawadlateef@xxxxxxxxx> wrote: > Hi Andrej, > > > On Mon, May 23, 2011 at 3:45 PM, Andrej Gelenberg > <andrej.gelenberg@xxxxxxx> wrote: >> Hi, >> >> >> heap, stack, buffer overflow? multiple threads? It is bit difficult to >> suggest something without some code. Have you tried to use gdb or >> valgrind? (do someone know if valgrind work on arm?) >> > > Thanks for replying. > > There is _no_ threading only while(1) loop, we have multiple processes > communicating through pipes but this problem is happening only in one > process hence I am assuming that something local to that process is > corrupting memory. > > Our root-filesystem don't have gdb support and I think valgrind is > _not_ supported on arm :( Try gdb-server that should fit in small root filesystem. http://www.delorie.com/gnu/docs/gdb/gdbserver.1.html > > Is there any possibility that the problem is related to some compiler > optimization or something along that line ? We are using gcc-4.2.0 > based tool-chain and Linux kernel 2.6.29. > > I can't post the code due to two main reasons: -- Its closed source > and its too big and I don't think that anyone wants to look at code > with around 20 cpp files and each file has hundreds of lines of code. > > Regards, > > Fawad Lateef > >> Regards, >> Andrej Gelenberg >> >> On 05/23/2011 04:41 PM, Fawad Lateef wrote: >>> Hello, >>> >>> I need some suggestions about how-to approach, find and fix a memory >>> corruption issue which is happening in a C/C++ very complex and large >>> code (code evolved over several years). Code is running on AT91SAM9260 >>> (armv5l architecture; single processor with preemption enabled) and >>> completely in Linux user-space. >>> >>> The problem is: >>> >>> -- We are calling a function which has three integer arguments. >>> With-in that function 2nd and 3rd arguments always gets corrupted >>> while 1st argument is fine. Just before calling that function printing >>> arguments is fine. >>> >>> Now it will be good if I can get some suggestions about whats >>> happening and how-to look into this problem. I am thinking that there >>> is some memory/stack corruption happening somewhere. >>> >>> Thanks in advance. >>> >>> -- Fawad Lateef >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Thanks, MJ -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html