segfault on arm Tegra 2

[kolonelkadat]

I have a piece of code causing a segfault on a client's device. The cpu is a Nvidia Tegra 250(Cortex-A9).

I'm sure i've done something stupid, but on all my test devices (x86, i.MX6S (cortex-a9), Exynos quad 4412 (cortex-a9), and ~6 that I dont know what they are) the code works as intended. The last time something like this happened it was a cpu hardware issue and I'm curious if any of you can point out what I've done wrong or if the client's chipset somehow doesnt support something im doing.

It's a simple unix server and from what I can gather from the client, the segfault is occuring in this area probably @ the memset but thats just a guess on my part

Code: [Select]

const char name[] = "\0TestServer";
int sockfd, newsockfd, servlen, n;
socklen_t clilen;
struct sockaddr_un cli_addr, serv_addr;
char buf[80];


int processors = std::thread::hardware_concurrency();


if ((sockfd = socket(AF_UNIX, SOCK_STREAM, 0)) < 0){
error("creating socket");
}

memset(&serv_addr, 0, sizeof(serv_addr));
serv_addr.sun_family = AF_UNIX;

memcpy(serv_addr.sun_path, name, sizeof(name) - 1);

servlen = sizeof(name) - 1 + sizeof(serv_addr.sun_family);

//bind the server, make sure it isnt already running
int bindResult = bind(sockfd, (struct sockaddr *) &serv_addr, servlen);
if (bindResult == EADDRINUSE) {
error("socket address already in use, shutting down");
}
if (bindResult < 0) {
error("binding socket");
}

listen(sockfd, 5);

//init vars for bytestream data
char operation;

int sigil = 1; //loop control variable
int32_t result = 0; //scan result to return to client
int32_t msg = 0;
int32_t tmp = 0;

while (sigil) {
//wait for a new connection
newsockfd = accept(sockfd, (struct sockaddr *) &cli_addr, &clilen);

The compiler is clang, if that matters.
Thanks in advance

[ataradov]

Does SF happen any time you run the program?

Did you intend to have \0 at the beginning of "\0TestServer"? sun_path is a null-terminated string, so all your copy operations are useless here.

[ale500]

But the memset is called with a pointer to a local on the stack... that is probably not it. Instead of guessing where it happens, I'd suggest you get a core dump... and check  you program (if it runs on linux) with valgrind, it is a very useful too to detect erroneous memory accesses like out-of-bounds accesses, reuse of freed memory and so on...
He is using memcpy to copy the null-initiated string, if it is so intended, then it is ok, memcpy doesn't care about \0s.

[ataradov]

then it is ok, memcpy doesn't care about \0s.

Yeah, but the rest of the functions (especially bind()) may care that they've been showed a zero length string while servlen is indicates otherwise.

[kolonelkadat]

yes the segfault happens every time on the client's device.
the "\0" indicates to the kernel that it is an abstract socket rather than a standard file socket.

as for the null char making the memcpy useless, I dont understand. memcpy doesnt care what is in the src buffer. outside of optimizations, its literally just a for loop setting dst:=src

eta:I will see if valgrind yields anything

[ataradov]

memcpy doesnt care what is in the src buffer.

But bind() does. You are passing full string length in servlen. While sun_path will have a truncated version.

Use strlen() in servlen calculation, just like man suggests.

[nctnico]

The memcpy could be the problem. I see sizeof(name)-1 which doesn't copy the 0 at the end of the string.

A good way to find the problem is to disable all optimisation, enable debugging info and run it from gdb so you can trace the problem back to the location of the problem.