There is nothing magical about a bad pointer problem going undetected for years. Depending on what the problem is, the same source code built using a different compiler, running on different hardware, or even running it at a different time of day may mask a problem until the right sequence of events happens in your program to expose the problem. 99.44% of the time (at least in my experience looking at bug reports against Solaris systems), the bug is in your code. The rest of the time, it may be a bug in the kernel, in a system library, or a hardware problem.

Without carefully analyzing your code, there is no way to guess at what the problem might be. You basically need to look at every line of code that allocates space, every line of code that uses a pointer (or an array subscript), and every line of code that frees space to verify that the pointer/array subscript is in bounds for the space allocated to that space/array) and that allocated space is not referenced after it is freed.

If you show us your code, we might spot the problem in seconds, or we might never figure it out. If you don't show us your code, there isn't anything we can do to help you other than suggest that you set breakpoints in your code, dump variables that seem to be corrupted, and add debugging statements until you identify the problem and fix it. But, be aware that adding a line of debugging code can easily change the way your program runs just enough to hide a problem. I.e., debugging bad pointers can be really hard.

You have not said anything yet that sounds like there was a bug on your old Solaris system nor that there is a bug on your new Linux system (although subtle differences in the ways functions are defined to behave on the two systems may well be your problem).