user767849
user767849

Reputation: 105

malloc / calloc crash on side-thread on Linux

I'm writing a server-client application in C sharing some informations. Server works in a two-thread mode - with main thread waiting for input and side thread responding to clients' requests. Client works like that too, but it waits for user input (from stdin) and if it receives proper command, it sends a request to a server and waits for response. The wait is done in a side thread processing responses. While this seems all fine and works on Ubuntu-based distro (I use Ultimate Edition 2.7) it crashes on some other distribution. Here's what happens.

Server works flawlessly as it is, but the client suffers from glibc detected crashes (I hope I typed it correctly). When it receives response, it parses its structure which contains:
a) header,
b) some static identifiers,
c) data section containing length and the data itself.

What happens is:
a) client receives packet,
b) client checks for size of it (at least sizeof(header) + sizeof(static_data) + sizeof(length) + data -- and data size is as big as length says)),
c) creates structure - conversion from buffer of chars to the structures above, d) creates some other structures storing those structures.

Structure is interpreted correctly. I tested it by sending 'fixed' structure to the client through the server's interface and by printing the original, sent data and received informations. So this is not the case. Everything is fine to point c).

To point d) I work on the buffer used to receive incoming packets (max size is specified and the buffer is of that size). To store the structures I got to data. I do it by:
a) allocating new memory of correct size
b) copying data.

I am not to discuss the method. It's all fine as long as it works. But as I said it does not on the other distro. It fails on MALLOC allocating memory in point a). And it fails on everything. My guess was that it could be a problem with thread-safety of malloc and / or printf on the other distro, but the problem is the main thread MOSTLY idles on scanf( .. ) method.
Back to the topic: it fails on anything:
char* buffer = (char*)malloc(fixed_size * sizeof(char))
STRUCT_T* struct = (STRUCT_T*)malloc(sizeof(STRUCT_T)) and so on. No matter what I try to allocate, it always throws the glibc detected error and always points to malloc method (even if it's calloc).

It's making me wonder what's wrong with that ? And this is my thread question. Looks a bit like I am overflowing 'memory space', but I doubt it as it always happen on first response receive. I'd be greatful for any help and can post more details if needed. Side threads are joinable.

Options with which I compile:
CC = gcc CFLAGS = -Wall -ansi --pedantic -c -O0 -g -std=c99 -pthread $(CC) $(CFLAGS) server.c -o server.o gcc server.o $(OBJECTS) -o server -pthread -lm
and includes in client.c file:
sys/fcntl.h netdb.h errno.h stdio.h unistd.h stdlib.h string.h time.h pthread.h math.h

I'm not a newbie with C and Linux, but I mostly work on Windows and C++, so this is rather disturbing. And as I said it works just fine on the distro I use, but it does not on some other while the buffer is parsed correctly.


Thanks in advance.

Upvotes: 0

Views: 2058

Answers (1)

frankc
frankc

Reputation: 11473

When malloc crashes, it's usually because you have previously stepped on the data it uses to manage itself (and free). It's difficult or impossible to diagnose at the point of the crash because the problem really happened at some previous time. As has already been suggested, the best way to catch where that previous memory overwrite occurred is to run your program through a program like valgrind, purify, insure++ etc. It will inform you if you overwrite something that you shouldn't. valgrind is free software and it likely to be installed already. It can be as simple as sticking the word valgrind in front of everything else on your client's invocation string.

Upvotes: 2

Related Questions