Upon calling addrtab = g_hash_table_new_full(g_int_hash, g_int_equal, g_free, NULL); the execution aborts and the following is reported: GLib-ERROR **: 15:23:58.535: ../../../glib/gmem.c:138: failed to allocate 11755944670652 bytes. What puzzles me is the amount of memory requested.
Now a bit of details: I'm writing in C using glib-2.66 on Ubuntu 20.04. Commenting out the previously reported line solves the error entirely. g_hash_table_new_full() is used elsewhere in the program without causing any error.
For completeness I'm posting the function that calls that g_hash_table_new_full()
void addr_advertise (hash_node_t* alice, hash_node_t* bob){
GHashTable* addrtab = NULL;
if ((alice->data->key != bob->data->key) && !(alice->data->attackerid == 1 && bob->data->attackerid == 1)) {
addrtab = g_hash_table_new_full(g_int_hash, g_int_equal, g_free, NULL);
if(alice->data->attackerid == -1){
//populate_honest_addr_table(addrtab, alice->data->known_peers);
}
else{
//add_malicious_to_table(addrtab);
}
execute_addr(simclock + FLIGHT_TIME, alice, bob, 5, simclock, alice->data->key, addrtab);
}
}
addr_advertise itself is called multiple times before causing the error.
As reported in gmem.c the error is caused by a g_malloc0() (line 138) that requests too much memory. How is it possible that g_malloc asks for so many bytes? Why previous executions of the same function work perfectly and most of all what could be the origin of the error?
Related
I am using Gurobi (9.0.3) C API to build a LP model and change the constraints to get different objective value. However, sometimes when I run the code, there is error about "triggered the breakpoint" and "heap has been corrupted" where I marked below. I noticed that the heap will be corrupted if memory is wrongly assigned, but I am not sure what to change with the model.
There are three functions in my code, first I will use constructLPmodel() to build original model and get the result using getSol_LP(). After that, updateLP() will be called several (100+) times to change constraints and get the result.
GRBenv *LPenv = NULL;
GRBmodel *LPmodel = NULL;
double LPobjectiveValue;
double constructLPmodel()
{
GRBloadenv(&LPenv, "LP.log");
GRBnewmodel(LPenv, &LPmodel, "LP", 0, NULL, NULL, NULL, NULL, NULL); //breakpoint sometimes lies here
// create variables and constraints
getSol_LP();
return LPobjectiveValue;
}
double updateLP()
{
int error = 0;
error = GRBupdatemodel(LPmodel); // breakpoint sometimes lies here
if (error) printf("Error in updating model\n");
getSol_LP();
return LPobjectiveValue;
}
void getSol_LP()
{
int error = 0;
double objVal;
GRBoptimize(LPmodel); // breakpoint sometimes lies here
GRBwrite(LPmodel, "LP.lp"); // breakpoint sometimes lies here
GRBwrite(LPmodel, "LP.sol");
error = GRBgetdblattr(LPmodel, GRB_DBL_ATTR_OBJVAL, &objVal);
if (error) goto QUIT;
LPobjectiveValue = objVal;
}
This sounds like a hardware issue. Maybe something is wrong with your memory. Have you tried reproducing this on another machine? Do you have a stack trace of the error, showing where it happens?
Without a (minimal) reproducible example, there is not much we can do to help you.
I have a 10k lines of code C program that sometimes crashes.
I cannot replicate that crash. All I can do is to wait for it to happen and then try to debug it.
This is what I get from drmingw
EXCEPTION PID=18632 TID=10612 ExceptionCode=0xc0000005 dwFirstChance=0
mypgr.exe caused an Access Violation at location 0000000000402CB2 in
module mypgr.exe Reading from location 0000000000000000.
AddrPC Params
0000000000402CB2 0000000000A862D0 0000000000000003 00000000035BE380 mypgr.exe!manage_ids [C:/Users/mn/Documents/code blocks/zbr/common.c # 440]
if(unique_id[i]->idd[32] != 0)
log_errors_to_file("xd2");
dbg_str_len = 0;
for(int xd = 0;xd < 32;xd++) { // ERROR IN THIS LOOP
if(ant_tb[j][k]->idd[xd] == 0)
break;
dbg_str_len++;
};
if(dbg_str_len != 32)
log_errors_to_file("xd3");
if(ant_tb[j][k]->idd[32] != 0)
log_errors_to_file("xd4");
I know this code does not make any sense but I tried many strange things to replicate the crash.
Anyway my debugger shows that below line is causing the problem
for(int xd = 0;xd < 32;xd++){if(ant_tb[j][k]->idd[xd] == 0) break;dbg_str_len++;};
But why? Is it possible to crash the app by just reading?
I have a piece of code in which malloc() makes the program pause, without neither really crashing, nor returning an error code (NULL).
Piece of code (has to be executed 24 times, stops at the 22th) :
fprintf(stderr, "malloc");
//-- copy sound
pitched_sound = malloc(sizeof(Mix_Chunk));
if (pitched_sound == NULL)
return -1;
*pitched_sound = *orig_sound;
pitched_sound->abuf = malloc(sound->alen / note_factor);
if (pitched_sound->abuf == NULL)
return -1;
fprintf(stderr, "mallocok.");
Any idea?
I'm running on a Rasperry Pi (ARM), could be related?
How could I debug this?
Many thanks!
I couldn't find anything similar to my Question. I hope there are some advices out there.
I noticed in the last time that I cannot find any readable and well structured way to deal with allocation errors and other initialization problems. The main problem is that during initialization there are many possible error paths and depending on where the error occurred you have to undo the changes made so far.
If you look at a simple example dealing with semaphores:
Any_Struct dosomething(void){
Any_Struct *a_struct;
sem_t *semaphore;
semaphore = malloc(sizeof(*semaphore));
if(semaphore == NULL){
return NULL;
}
if(sem_init(semaphore, 0, 0) == -1){
free(semaphore);
return NULL;
}
a_struct = malloc(sizeof(*a_struct));
if(a_struct == NULL){
sem_destroy(semaphore);
free(semaphore);
return NULL;
}
a_struct->sem = semaphore;
return a_struct;
}
As you can see this way has the big disadvantage to grow very fast. Each dynamic object i need produces a very large overhead for error handling. Moreover this is very error prone because it is very likely to forget a free() after adding new objects.
There are three solutions to this I can think of:
Encapsulate "sub initializations" in functions (e.g. semaphore creation could be a function create_semaphore())
First allocate all memory (which does not depend on each other) and if anything went wrong free one after the other:
/* ..... */
semaphore = malloc(sizeof(*semaphore));
a_struct = malloc(sizeof(*a_struct));
if(semaphore == NULL || a_struct == NULL){
sem_destroy(semaphore);
free(semaphore);
return NULL;
}
if(sem_init(semaphore, 0, 0)){
free(a_struct);
free(semaphore);
return NULL;
}
return a_struct;
Use goto ( I know, I am not allowed to do that)
But all the mentioned "solutions" have their own disadvantages and do not satisfy me.
So are there any better options or maybe best practices? Or would you say: "just stop wracking your brain abut such a stupid thing"?
I'm pretty new to C. When I run the following code for a hash table under Valgrind:
table *insertObject (table *h, int pref, char ch)
{
struct node x;
int i;
if (ch < 0)
{
ch=256-ch;
}
x.chr=ch;
x.pref=pref;
i = hash(pref, ch, h->size);
while (h->hash[i].pref!=0)
{
i++;
}
h->hash[i]=x;
h->size++;
return h;
}
I get the following error:
==9243==
==9243== Process terminating with default action of signal 11 (SIGSEGV)
==9243== Bad permissions for mapped region at address 0x6018A4
==9243== at 0x4009CD: insertObject (encode.c:119)
==9243== by 0x4008E3: main (encode.c:55)
Line 119 is the line
h->hash[i]=x;
The funny thing is, when I run the whole code through a debugger, it works fine 90% of the time. However, for some special cases, the code segfaults, and the debugger tells me this is also the culprit. What's wrong?
The error is due to an incorrect memory access, basically your application is trying to access a memory area which is not mapped in its memory space.
Quite likely the value of i exceeds the limits of the hash array. I cannot be more precise because I do not how the hash function works and what perf stands for.
However, you should verify the value of i with a debugger, in the 10% of case where the application does not work.
P.S. a program should work fine 100% of time.