Hi,

I did my porting from UNIX to LINUX and was able to compile successfuly without many critical warnings.

However, when i tried to execute the binary, it did not run properly. When i executed the binary with GDB, it showed error as such:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 139641094334208 (LWP 30988)]
0x0000003be2130e3c in __strncpy_ssse3 () from /lib64/libc.so.6
(gdb) WHERE
#0 0x0000003be2130e3c in __strncpy_ssse3 () from /lib64/libc.so.6
#1 0x0000000000468833 in ?? ()
#2 0x0000000000000023 in ?? ()

It was compiled with gcc (GCC) 4.4.5 on Red Hat Enterprise Linux Server release 6.1. The same specs applied for the run environment. Has anyone encountered this before? Any advice on how to solve this?

Was that also a port from 32 bit to 64 bit?

You are implying the code ran, without symptoms of this bug, on the Unix system. Correct me if I'm misunderstanding that. Assuming it ran correctly, was that a 32 bit system?

It is possible those warnings include an indication of the bug in your program.

Did you compile with debug info, so that GDB would show you the name of the calling function if it understood the call stack?

This will be a little harder to debug since you can't see the name of the calling function. There are three likely possibilities for why you can't see the name of the calling function:

1) You didn't compile with debug info.
2) __strncpy_ssse3 has a strange stack frame that confuses GDB (I think that one is most likely)
3) The bug in your program caused __strncpy_ssse3 to corrupt its return information.

You seem to be assuming the problem might be in GCC or in Red Hat or in the libc code where the symptom occurred, so that someone else might have seen the same problem before.

That is so unlikely it is not worth considering. The problem is a bug in the program you ported. The fact that it ran on some other system does not mean the bug wasn't there. It could mean the bug had no symptom. If the other system was 32 bit, it could mean the bug was a non portable operation that fails in 64-bit but works in 32-bit.

If you have the right 32-bit development package(s) installed, you can build the program to run as 32-bit even though the Red Hat is 64 bit. Any 64 bit vs. 32 bit portability bug in your program would depend only on whether the program is built 32 bit, not on whether the OS is 32 bit.

Add the option -m32 to your gcc commands and see whether that:
A) Fails to build, indicating you need to install some 32-bit packages.
B) Makes the program run symptom free, which strongly hints but does not prove that the bug was a 32 bit portability issue.
C) Changes the symptom, possibly to one easier to diagnose, which is likely for most other kinds of program bugs.
D) Gives essentially the same symptom (which is very unlikely) so the effort was wasted and you must try something else.

BTW, assuming this program has a similar memory map to the one you posted in an earlier thread:
http://www.linuxquestions.org/questi...8/#post4668395
We can estimate that 0x0000000000468833 is the correct address for the caller of strncpy (so GDB wasn't confused by the strncpy stack frame) making it very likely that this caller of strncpy corrupted its own stack frame by this call to strncpy.

If that is correct, we can deduce that the destination of the strncpy was a local variable of the function calling strncpy and that the size was too large for the allocation of that variable (so you didn't use the n correctly to limit the strncpy).

So one way to find the bug is to find all the strncpy calls in your code and look closely at any whose destinations are local variables and see whether the n value might be too high for the allocation of that destination.

I usually use "up" to go into the stack trace. I haven't used "where" before, however on a seg fault you should be able to go up the stack to at least step through the code to see what line of code it crashed on.

If you can't then maybe you don't have your debug flags enabled.

Or you are having a stack crash that is showing up as segfault, only to show you a corrupt stack.

@johnsfine I just read what you wrote. Cools beans. Can you explain a little more about how to read the memory address to determine the nature of the crash...???

I was just trying to estimate whether the 0x468833 was the actual return address of the function where the seg fault occurred. Clearly the #2 line is worthless garbage. But #1 is less obvious.

In the other thread, I saw

So the range 0x400000-0x51d000 contains the executable code of the top level module of that process. That is a rather narrow range (within 64 bit addressing) that contains the 0x468833 that might be a return address in the current thread. So it seems very likely that is a return address.

So the lack of a function name on line #1 indicates lack of deg info, rather than a misunderstood or corrupt stack. But the garbage return address on #2 indicates a misunderstood or corrupt stack. At that level, I was estimating that corrupt is more likely than misunderstood. So I was estimating that function corrupted its own stack frame.

It is all guess work with this little info.

If I were debugging it myself, I would look at the asm instructions around the point of failure and look at the register values at the point of failure, as well as the stack. Then I could know for sure whether/what part of the stack was corrupted and probably know why.