segfault on arm Tegra 2 - Page 1
Forum section: electronics / general

author: kolonelkadat
author_rank: Regular Contributor
timestamp: February 27, 2016, 02:35:19 am
content: 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 partCode:const char name[] = "\0TestServer";int sockfd, newsockfd, servlen, n;socklen_t clilen;struct sockaddr_un cli_addr, serv_addr;char buf;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 runningint 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 datachar operation;int sigil = 1; //loop control variableint32_t result = 0; //scan result to return to clientint32_t msg = 0;int32_t tmp = 0;while (sigil) {//wait for a new connectionnewsockfd = accept(sockfd, (struct sockaddr *) &cli_addr, &clilen);The compiler is clang, if that matters.Thanks in advance

author: ataradov
author_rank: Super Contributor
timestamp: February 27, 2016, 03:15:53 am
content: 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.

author: ale500
author_rank: Frequent Contributor
timestamp: February 27, 2016, 04:22:09 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 27, 2016, 04:24:34 am
content: Quote from: ale500 on February 27, 2016, 04:22:09 amYeah, but the rest of the functions (especially bind()) may care that they've been showed a zero length string while servlen is indicates otherwise.

author: kolonelkadat
author_rank: Regular Contributor
timestamp: February 27, 2016, 04:27:30 am
content: 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:=srceta:I will see if valgrind yields anything

author: ataradov
author_rank: Super Contributor
timestamp: February 27, 2016, 04:30:33 am
content: Quote from: kolonelkadat on February 27, 2016, 04:27:30 amBut 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 27, 2016, 07:56:43 am
content: 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.