I am trying to use a malloc of short, something like
typedef union _SOME_STRUCT_ {
struct {
USHORT u:4;
USHORT v:4;
USHORT w:4;
} x;
USHORT word;
} SOME_STRUCT, *PSOME_STRUCT;
PSOME_STRUCT p = malloc (sizeof (SOME_STRUCT));
if (p) {
p->x.u = 0;
}
free (p); // **** RANDOMLY CRASHING HERE ****
I am debugging for a couple of days and clueless,
Note(edited): Linux, and gcc Version 3.4.6 20060404
ISSUE FOUND USING VALGRIND
But then, I would like to document it here so that my fellow developers might be aware of such a situation ...
I had actually defined the structure as
typedef union _SOME_STRUCT_ {
struct {
USHORT u:4;
USHORT v:4;
USHORT w:4;
} x;
USHORT word;
} ALBUM, *PALBUM;
and some-where else in the code I had also defined
#define ALBUM "album"
And so, sizeof (ALBUM) was referring to the #define value rather than the typedef and hence the issue.
The thing that amazes me is,
Is this allowed in C?
Try to pass your program through valgrind , an open source program and totaly free, maybe it could help you to see where is the issue. Don't forget to compile with debug symbols: gcc -g [etc] .
Hope this help..
This version of the code works for me.
#include <stdio.h>
#define USHORT unsigned short
typedef union _SOME_STRUCT_ {
struct {
USHORT u:4;
USHORT v:4;
USHORT w:4;
} x;
USHORT word;
} SOME_STRUCT, *PSOME_STRUCT;
int
main(int c, char *argv[])
{
PSOME_STRUCT p = malloc (sizeof (SOME_STRUCT));
if (p) {
p->x.u = 0;
}
free (p); // **** Properly exiting after this ****
}
This is GDB debug from a Cygwin on Windows XP.
(gdb) p/x sizeof(PSOME_STRUCT)
$1 = 0x4
(gdb) p/x sizeof(p)
$2 = 0x4
(gdb) p/x sizeof(*p)
$3 = 0x2
(gdb) n
23 if (p) {
(gdb) p/x *p
$4 = {x = {u = 0xc, v = 0x4, w = 0x3}, word = 0x534c}
Ignore the values in $4, data is uninitialized.
Program exited normally.
Do you have something else in the code besides these lines?
Edit: and, free(0); is a valid operation.
Might be an alignment issue. Does it still crash if you do something like this:
struct {
USHORT u:4;
USHORT v:4;
USHORT w:4;
USHORT :4;
} x;
The problem is not with the code but something that is happening before or in another thread.
I would reduce sections of the program until it stops crashing and then add it back in step by step until you figure out what section is causing this. Depending on the OS/Platform you could also try some memory checking tools, valgrind/_crtdebug etc..
If this issue is happening where you could debug it you could start your debug session with a call to memcheck.
A cause for a crash for memory is most often heap or freeing the same pointer twice.
If you're doing stuff in between the malloc and free, you could be overrunning a different array by accident and corrupting your own stack
(if 'p' doesn't happen to be in a register, and you overrun a statically-allocated array and hit the place on the stack where 'p' is stored, you will then later attempt to free random crap, hence the segfault)
You're unconditionally calling free() without checking if the malloc succeeded, so if the malloc failed and p is a NULL pointer, then you're calling free(NULL).
Move the free inside the if (p) block.
This might not be the cause of the crashes, and shouldn't be if not memory-constrained, but is a bug nonetheless.
Added later: doh, free(NULL) is explicitly allowed, per http://www.opengroup.org/onlinepubs/009695399/functions/free.html -- sorry.
What if you put free(p) in your if? Maybe (unlikely) malloc is failing...
Related
So I'm building a virtual machine, and trying to make it as cross platform as possible, and suddenly encountering a strange error. There is a let instruction for my machine, which allocates memory for a variable in the memory of the machine and assign that variable with a value. In short, the let function calls getAddress to get the address of the variable. getAddress checks if the variable is already defined, and returns the address. If the variable is not defined, getAddress calls memallocate to allocate memory for the variable, and returns the address. Here is the definition of the functions :
static uint16_t memallocate(Machine *m, char *symbol){
uint16_t allocationAddress = getFirstFree(*m);
SymbolTable *newSymbol = (SymbolTable *)malloc(sizeof(SymbolTable));
newSymbol->symbolName = strdup(symbol);
newSymbol->next = NULL;
newSymbol->mema = allocationAddress;
if(m->symbolTable==NULL){
m->symbolTable = newSymbol;
}
else{
SymbolTable *temp = m->symbolTable;
while(temp->next!=NULL)
temp = temp->next;
temp->next = newSymbol;
}
m->memory[allocationAddress].acquired = 1;
m->memory[allocationAddress].data.value = 0;
m->occupiedAddress++;
return allocationAddress;
}
uint16_t getAddress(Machine *m, char *symbol){
SymbolTable *table = m->symbolTable;
while(table!=NULL){
if(strcmp(symbol, table->symbolName)==0){
return table->mema;
}
table = table->next;
}
uint16_t address = memallocate(m, symbol); // Here is the segfault happening
return address;
}
This code compiles and runs pretty well on Linux, but on Windows I'm getting a segfault on the memallocate call. Since memallocate is directly passed the arguments of getAddress, and the arguments both being a pointer, they shouldn't change. But while debugging through CLion, I'm seeing gibberish arguments to the memallocate call, which is indicating some kind of stack violation(may be). Again, it is ONLY happening in Windows. Can anybody tell me what is going wrong with my code?
Full code for the project can be found at GitHub.
I took your code and run it on linux through valgrind:
==13768== Conditional jump or move depends on uninitialised value(s)
==13768== at 0x109ABE: getAddress (in /home/vonaka/VirtualMachine/machine)
==13768== by 0x10B714: let (in /home/vonaka/VirtualMachine/machine)
==13768== by 0x109425: run (in /home/vonaka/VirtualMachine/machine)
==13768== by 0x109F64: main (in /home/vonaka/VirtualMachine/machine)
==13768== Uninitialised value was created by a heap allocation
==13768== at 0x4C2BE7F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd
==13768== by 0x109C2F: main (in /home/vonaka/VirtualMachine/machine)
==13768==
So (luckily for us) it's not a Windows specific problem. The trick is that on the first call of getAddress (when m->symbolTable is NULL) you call getFirstFree(*m) at the beginning of memallocate, but look at this function:
static uint16_t getFirstFree(Machine m) {
uint16_t add = 0;
while(m.memory[add].acquired)
add++;
return add;
}
m.memory[i].acquired for i between 0 and number_of_instructions_in_your_input_file - 1are all equal to 1 as you initialize them in writeInstruction, but m.memory[number_of_instructions_in_your_input_file].acquired is not initialized yet.
So something like this will resolve your problem:
void writeInstruction(Machine *m, uint16_t add, Instruction ins) {
m->memory[add].acquired = 1;
m->memory[add].type = INSTRUCTION;
m->memory[add].data.instruction = ins;
m->occupiedAddress++;
if(add + 1 < NUM_MEM)
m->memory[add + 1].acquired = 0;
}
Or maybe this is more elegant (if it's works):
static uint16_t getFirstFree(Machine m) {
uint16_t add = 0;
while (m.memory[add].acquired && add < m.occupiedAddress)
add++;
return add;
}
Edit:
First of all about your comment:
By default, the members of the structure is initialised as 0
It's just not true!
Now about why you have segfault without malloc and how it's connected with valgrind's warning.
You have variable m of type Machine and some other variables in the stack, m contains Cell memory[NUM_MEM] and there is acquired in each Cell (which are not initialized!). Your input file contains let's say 88 instructions, so first 88 acquired will be correctly initialized after 88 calls of writeInstruction. Then program start to execute your instructions by calling some functions including memallocate and getFirstFree. In this loop:
while(m.memory[add].acquired)
add++;
for any add m.memory[add].acquired very likely can be different from 0, so once add is equal to NUM_MEM you have segfault.
Why it's not happening with malloc? Simply because you are lucky (but it's not a good luck), your heap is 'cleaner' than stack. Why it's happening only in Windows? Because this time you were not so lucky (I don't have segfault even in Windows).
I'm programming in C, and when I use Valgrind to check memory errors, the next error has shown:
==9756== Invalid write of size 4
==9756== at 0x40164D: main (flowTracker.c:294)
==9756== Address 0x24 is not stack'd, malloc'd or (recently) free'd
The line 294 of flowTracker.c is the next:
tabla_hash[clave_hash]->contador++;
And the declaration of tabla_hash is:
#define TAMANHO_TABLA 1048576
typedef struct{
int tiempo_ini;
int tiempo_ult;
uint8_t quintupla[13];
int num_bytes;
int num_SYN;
int num_ACK;
int contador;
double pack_s;
double bits_s;
} FlujoIP;
FlujoIP *tabla_hash[TAMANHO_TABLA];
As 4566976 pointed out, tabla_hash[clave_hash] is (probably) NULL. That's just a guess, as you haven't provided an MCVE which reproduces the issue without us having to fill in the blanks or fix compiler errors...
It seems to me as though you probably meant to declare tablahash like so: FlujoIP tabla_hash[TAMANHO_TABLA]; (though, wow! That's a huge array)... and you should then be able to change -> to . like so: tabla_hash[clave_hash].contador++;
Alternatively, if you were to precede the offending statement with if (tablahash[clave_hash] == NULL) { tablahash[clave_hash] = malloc(sizeof tablahash[clave_hash][0]); } or something, that might also be appropriate... Don't forget to free all of the items within your huge array.
i recently learnt about memalloc() and free() and i was just wondering if there was a way to appropriately check if all the memallocs are appropriately being freed?
I have this code right here for an implementation of doubly linked list, and im unclear whether id need to go through every node and deallocate each p1 and p2, or does doing it once count?:
struct s {
int data;
struct s *p1;
struct s *p2;
};
void freedl(struct s *p)
{
if(p->p1 != NULL)
{
printf("free %d \n", p->p1->data);
}
if(p->p2 != NULL)
{
freedl(p->p2);
}
else
{
printf("free last %d", p->data);
free(p);
}
}
int main(void) {
struct s *one, *two, *three, *four, *five, *six;
one = malloc(sizeof *one);
two = malloc(sizeof *two);
three = malloc(sizeof *three);
four = malloc(sizeof *four);
five = malloc(sizeof *five);
six = malloc(sizeof *six);
one->data = 1;
one->p1 = NULL;
one->p2 = two;
two->data = 2;
two->p1 = one;
two->p2 = three;
three->data = 3;
three->p1 = two;
three->p2 = four;
four->data = 4;
four->p1 = three;
four->p2 = five;
five->data = 5;
five->p1 = four;
five->p2 = six;
six->data = 6;
six->p1 = five;
six->p2 = NULL;
freedl(one);
return EXIT_SUCCESS;
}
and I'd just like to make sure I'm doing it right!
The answer is "yes"; exactly how hard it is depends on what OS you're in.
If you're in Linux, Mac OS X or one of the BSDs (FreeBSD, OpenBSD, ...):
(and possibly Haiku)
You can use an utility called valgrind. It is an excellent utility, designed for (among other things) exactly that --- checking for memory leaks.
The basic usage is simple:
valgrind ./my-program
It is a complex utility though, so I'd recommend checking out the valgrind manual for more advanced usage.
It actually does a far more than that, in that it can detect many (but not all) out-of-bounds accesses and similar problems. It also includes other tools that may come useful, such as callgrind for profiling code.
Do note, however, that valgrind will make your program run very slowly, due to the way it operates.
Any other OS (incl. Windows):
Unfortunately, there is no such utility for Windows (no free ones, anyways; and the commercial ones costed a small fortune, last I've checked --- and none does quite as much as valgrind & friends can).
What you can do, however, is implement macros and check manually on exit:
#define malloc(size) chk_malloc(size, __FILE__, __LINE__)
#define free(ptr) chk_free(ptr, __FILE__, __LINE__)
// etc... for realloc, calloc
...
// at start of main():
atexit(chk_report); // report problems when program exits normally
You then have to implement chk_malloc, chk_free and so on. There can be some "leaks", however, if you do things such as setAllocator(malloc). If you're okay with losing line information, you can then try doing:
#define malloc chk_malloc // chk_malloc now only takes 1 argument
#define free chk_free
...
There are certain hacks which would allow you to keep file/line info even with this #define, but they would seriously complicate matters (it would involve basically hacking closures into C).
If you don't want to change the code in any way, you could try your luck with replacing just those functions (by replacing the stdlib with your own shim DLL), though you won't get file/line information that way. It might also be problematic if the compilation was done statically, or if the compiler has replaced it with some intrinsic (which is unlikely for malloc, but not inconceivable).
The implementation can be very simple, or it can be complex, it's up to you. I don't know of any existing implementations, but you can probably find something online.
System allocators have some way of getting statistics (such as bytes allocated) out of them. (mallinfo on linux). At the beginning of your program you should store the number of bytes allocated and at the end you need t make sure the number is the same. If the number is different, you have a potential memory leak.
Finding that leak is another story. Tools like valgrind will help.
You can valgrind but it can be a little bit slow
Or something buildin in compiler. For example in clang (I think that in gcc 4.9 too) there are LeakSanitizer:
$ cat example.c
int main()
{
malloc(100);
return 0;
}
$ clang -fsanitize=leak -g example.c -fsanitize=address
$ ASAN_OPTIONS=detect_leaks=1 ./a.out
=================================================================
==9038==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 100 byte(s) in 1 object(s) allocated from:
#0 0x46c871 (/home/debian/a.out+0x46c871)
#1 0x49888c (/home/debian/a.out+0x49888c)
#2 0x7fea542e4ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
SUMMARY: AddressSanitizer: 100 byte(s) leaked in 1 allocation(s).
I'm running into a strange situation with passing a pointer to a structure with a very large array defined in the struct{} definition, a float array around 34MB in size. In a nutshell, the psuedo-code looks like this:
typedef config_t{
...
float values[64000][64];
} CONFIG;
int32_t Create_Structures(CONFIG **the_config)
{
CONFIG *local_config;
int32_t number_nodes;
number_nodes = Find_Nodes();
local_config = (CONFIG *)calloc(number_nodes,sizeof(CONFIG));
*the_config = local_config;
return(number_nodes);
}
int32_t Read_Config_File(CONFIG *the_config)
{
/* do init work here */
return(SUCCESS);
}
main()
{
CONFIG *the_config;
int32_t number_nodes,rc;
number_nodes = Create_Structures(&the_config);
rc = Read_Config_File(the_config);
...
exit(0);
}
The code compiles fine, but when I try to run it, I'll get a SIGSEGV at the { beneath Read_Config_File().
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000407d0a in Read_Config_File (the_config=Cannot access memory at address 0x7ffffdf45428
) at ../src/config_parsing.c:763
763 {
(gdb) bt
#0 0x0000000000407d0a in Read_Config_File (the_config=Cannot access memory at address 0x7ffffdf45428
) at ../src/config_parsing.c:763
#1 0x00000000004068d2 in main (argc=1, argv=0x7fffffffe448) at ../src/main.c:148
I've done this sort of thing all the time, with smaller arrays. And strangely, 0x7fffffffe448 - 0x7ffffdf45428 = 0x20B8EF8, or about the 34MB of my float array.
Valgrind will give me similar output:
==10894== Warning: client switching stacks? SP change: 0x7ff000290 --> 0x7fcf47398
==10894== to suppress, use: --max-stackframe=34311928 or greater
==10894== Invalid write of size 8
==10894== at 0x407D0A: Read_Config_File (config_parsing.c:763)
==10894== by 0x4068D1: main (main.c:148)
==10894== Address 0x7fcf47398 is on thread 1's stack
The error messages all point to me clobbering the stack pointer, but a) I've never run across one that crashes on entry of the function and b) I'm passing pointers around, not the actual array.
Can someone help me out with this? I'm on a 64-bit CentOS box running kernel 2.6.18 and gcc 4.1.2
Thanks!
Matt
You've blown up the stack by allocating one of these huge config_t structs onto it. The two stack pointers on evidence in the gdb output, 0x7fffffffe448 and 0x7ffffdf45428, are very suggestive of this.
$ gdb
GNU gdb 6.3.50-20050815 ...blahblahblah...
(gdb) p 0x7fffffffe448 - 0x7ffffdf45428
$1 = 34312224
There's your ~34MB constant that matches the size of the config_t struct. Systems don't give you that much stack space by default, so either move the object off the stack or increase your stack space.
The short answer is that there must be a config_t declared as a local variable somewhere, which would put it on the stack. Probably a typo: missing * after a CONFIG declaration somewhere.
I am writing a C program for a 8051 architecture chip and the SDCC compiler.
I have a structure called FilterStructure;
my code looks like this...
#define NAME_SIZE 8
typedef struct {
char Name[NAME_SIZE];
} FilterStructure;
void ReadFilterName(U8 WheelID, U8 Filter, FilterStructure* NameStructure);
int main (void)
{
FilterStructure testStruct;
ReadFilterName('A', 3, &testFilter);
...
...
return 0;
}
void ReadFilterName(U8 WheelID, U8 Filter, FilterStructure* NameStructure)
{
int StartOfName = 0;
int i = 0;
///... do some stuff...
for(i = 0; i < 8; i++)
{
NameStructure->Name[i] = FLASH_ByteRead(StartOfName + i);
}
return;
}
For some reason I get a link error "?ASlink-Error-Could not get 29 consecutive bytes in internal RAM for area DSEG"
If I comment out the line that says FilterStructure testStruct; the error goes away.
What does this error mean? Do I need to discard the structure when I am done with it?
The message means that your local variable testStruct couldn't be allocated in RAM (or DSEG that should be DATA SEGMENT of your binary), since your memory manager couldn't find 29 consecutive bytes to allocate it.
This is strange since your struct should be 8 bytes long.. but btw it's nothing to do with discarding the structure, this seems a memory management problem.. I don't know 8051 specs so well but it should be quite limited right?
EDIT: looking at 8051 specs it seems it just has 128 bytes of RAM. This can cause the problem because the variable, declared as a local, is allocated in internal RAM while you should try to allocate it on an external RAM chip if it's possible (using the address/data bus of the chip), but I'm not sure since this kind of microcontroller shouldn't be used to do these things.
you've run out of memory....by the looks of it.
try moving it out as a global variable, see if that makes it better.
Just a guess: 8051 has only 128 or 256 bytes of "internal RAM". Not so much... It can use part of it as stack and part for registers. Maybe your "large" (8 bytes!!!) structure on the stack forces the compiler to reserve too much stack space inside the internal memory. I suggest to have a look into the linker map file, maybe you can "rearrange" the memory partition. The massage says "consecutive bytes", so perhaps there is still enough space availabe, but it's fragmented.
Bye