inet_ntoa() Segmentation Fault

[xtknight]

Whenever I try to read data returned from the inet_ntoa() command, I get a segmentation fault. I can run the function itself without setting a variable to the return value, and it gets past that line fine as you can see in my first trial.

Prototype for inet_ntoa: char *inet_ntoa(struct in_addr in);

I have tried several things to get at the data returned by this function, but all have failed. You can see my trials in the 'attached code'.

It seems this guy has a very similar problem, but it's beyond me what they did to fix it.

I'd appreciate it if someone could tell me where to go from here. Thanks in advance.

Edit: fixed link.

 

[DaveSimmons]

From your link:
"It seams that the structures must start at an address which is dividable by 4. when you use malloc, this is automatically done:
pktbuf = malloc(frame_header.bytes_caped + 1);
So the structure pktbuf starts at a 4 byte boundary. But now you assign a new structure inside the existing buffer:
ip = (struct ip*)(pktbuf + size_ethernet);
which is 14 bytes inside pktbuf. But it should have been 12 or 16 to keep a 4 byte boundary."


what this is getting at is that your clientname..sin_addr may not be aligned properly in memory

 

[Kyteland]

>No error ("success" is printed so it got past inet_ntoa() without errors)
The reson for this is because your function returns a null pointer to indicate an error state. If you don't check the return value your program will continue to execute, oblivious to the fact that it is in an error state.

 

[xtknight]

Are you saying that inet_ntoa is returning a null pointer because it's being given misaligned (and thus false) data, and accessing the null pointer causes the segmentation fault?

 

[xtknight]

The code below crashes after "success" (before the port can be printed).

The inet_ntoa() function converts the Internet host address
in given in network byte order to a string in standard
numbers-and-dots notation. The string is returned in a statically
allocated buffer, which subsequent calls will overwrite.

I'm not sure what this means. Do I need to use the same static char* every time? I just wonder why this function is so different from any other. I've never had so much trouble getting a return value, it's frustrating. Thanks for the help...

 

[Cerebus451]

The reference to statically allocated buffer means that inet_ntoa does not allocate a new buffer for each call. In the example below, both calls return a pointer to the same string (so in effect, a & b would be equal), and the code snippet would print the same string twice (that being a string representation of someotheraddress.

In the link you provided, the issue at hand was that the original author was trying to pass a non-double word aligned integer to the function. His problem was the code was not making it into his function call (which is difficult to see since all of his calls where made inside of printf calls, making it difficult to see which function was faulting). The only problem I could see with your code is that if for some inexplicable reason the inet_ntoa call is not creating a null-terminated string. You could try using a memcpy to get exactly 16 bytes from the string, an example of which is in the second half of the attached code below.

 

[xtknight]

char buf[17];
memset (buf, 0, 17); //this line works fine
memcpy (buf, inet_ntoa (clientname.sin_addr), 16); //it crashes at this one (Segmentation Fault)

Even if I pass a zero to inet_ntoa instead of clientname.sin_addr, it still crashes. You'd think a zero would give you "0.0.0.0", or something like that.

It must be a bug in the glibc library. This occurs in root too, so I have permission to access any memory.

Even a C file as simple as the attached causes a Segmentation Fault in both user and root mode so I guess I'm screwed. This is the only output during compilation (gcc 4.0.3-1ubuntu5/amd64):

inetntoa.c: In function ?main?:
inetntoa.c:4: warning: incompatible implicit declaration of built-in function ?memset?
inetntoa.c:5: warning: incompatible implicit declaration of built-in function ?memcpy?
inetntoa.c:5: warning: passing argument 2 of ?memcpy? makes pointer from integer without a cast
inetntoa.c:6: warning: incompatible implicit declaration of built-in function ?printf?

None of which seems like it would cause this problem.

 

[Cerebus451]

Originally posted by: xtknight
char buf[17];
memset (buf, 0, 17); //this line works fine
memcpy (buf, inet_ntoa (clientname.sin_addr), 16); //it crashes at this one (Segmentation Fault)

Even if I pass a zero to inet_ntoa instead of clientname.sin_addr, it still crashes. You'd think a zero would give you "0.0.0.0", or something like that.

It must be a bug in the glibc library. This occurs in root too, so I have permission to access any memory.

Even a C file as simple as the attached causes a Segmentation Fault in both user and root mode so I guess I'm screwed. This is the only output during compilation (gcc 4.0.3-1ubuntu5/amd64):

inetntoa.c: In function ?main?:
inetntoa.c:4: warning: incompatible implicit declaration of built-in function ?memset?
inetntoa.c:5: warning: incompatible implicit declaration of built-in function ?memcpy?
inetntoa.c:5: warning: passing argument 2 of ?memcpy? makes pointer from integer without a cast
inetntoa.c:6: warning: incompatible implicit declaration of built-in function ?printf?

None of which seems like it would cause this problem.

I copied and pasted your code into a file on our AIX machine and it compiled and ran just fine, so it does appear to be something in the library. You might want to try including the necessary header files, just in case the implementation uses a macro in there somewhere. The correct set should be:
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

I also noticed that you are working with a 64-bit compiler. Not sure if that would cause issues or not. I recompiled using the 64-bit option on AIX and it still compiled and ran without issue. Our Linux box isn't 64-bit and is RedHat based, but it also compiles and runs the code just fine.

 

[xtknight]

Wow, thanks a bunch. That solved the problem. I was missing #include <arpa/inet.h>

Now that I added it, nothing that caused a segmentation fault before does anymore and it works as expected. Thanks again!

 

[tuket]

Hello, I must say that I registered in this forum just to say THANK YOU.
Including #include <arpa/inet.h> did the trick
The reason is that when the good definition of the function is missing, there is a generic function prototype that returns int. But the actual function should return a char*. The casting produces a bad pointer. Glad I found this thread, I was going crazy!

 

[deustroop]

Hello, I must say that I registered in this forum just to say THANK YOU.
Including #include <arpa/inet.h> did the trick
The reason is that when the good definition of the function is missing, there is a generic function prototype that returns int. But the actual function should return a char*. The casting produces a bad pointer. Glad I found this thread, I was going crazy!

You're welcome.Any Time. 2006 was a particularly good year.