after executing the below function on an embedded system (esp32), the assertion in heap_tlsf.c fails, my code is:
remained_data = (char *)calloc(lbws - where_to_insert + 2, sizeof(char));
the lbws - where_to_insert + 2 evaluates around 1100, this call will panic and gives the below assertion error:
assert failed: insert_free_block heap_tlsf.c:239 (current && "free list cannot have a null entry")
I can't figure out what is the meaning of this assertion, and what is the cause for it, so as the solution for it.
so what should I do to fix this? thank you.
Related
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?
I'm developing an app which receives a continuous flow of data using ble, at this moment I properly read the flow sent by the device, but in fact I don't know how to interpret it.
This is my onCharacteristicChanged function
override fun onCharacteristicChanged(
gatt: BluetoothGatt,
characteristic: BluetoothGattCharacteristic?
) {
if (characteristic != null && characteristic.properties == BluetoothGattCharacteristic.PROPERTY_NOTIFY) {
Log.e(TAG, "**THIS IS A NOTIFY MESSAGE")
}
if (characteristic != null) {
data = characteristic.value
Log.e("onCharacteristicChanged", "Datos:")
Log.e("onCharacteristicChanged", "$data")
val dataparsed = data?.joinToString ( " : " )
Log.e("onCharacteristicChanged", "$dataparsed")
broadcastUpdate("com.np.lekotlin.ACTION_DATA_AVAILABLE")
}
}
This function is called every time the device sends me some info, returning an exit like this one:
Where we can see two interpretations of the same data
The data without treatment (the bytearray):
[B# ****
And the data after the joinToString (function I thought it would help me casting into hexa):
** : **: **: **: **: **: **: **: **: ** <-- But here there are negative numbers!!
My problem comes when I compare this output with the returned by another software I am using, CySmart
Which returns me something like
07:94:02:5A:56:00:76:35:00:00
07:2F:02:5F:45:00:B0:36:00:00
07:E4:01:50:47:00:6D:37:00:00
07:0C:02:53:4A:00:56:38:00:00
This output obviously follows a pattern, the first 7 and the 2 last group of 0s, for example but the negative numbers are baffling me.
So, in summary, my question is, exist any native way in kotlin to cast from bytearray to hexa? (without negative numbers)
In case I'm already casting it properly do you figure how can I treat, or which is the patron with the negatives numbers? It seems like 2's complement or something like that, but I don't know it surely.
Lots of thanks in advise.
As others have already mentioned having a negative number in a byte array only means that the number is larger than 127.
As for your question on how to display them as hex, you can use the built-in string formatting functions. You can add a transform block to your joinToString call which can convert your byte to a hex string:
val dataparsed = data?.joinToString ( " : " ) { "%02x".format(it) }
This way your output will be formatted correctly.
I'm new to using GTK. Here is a small section of my code. The aim is to copy the entire current line. The contents are stored in "line". "start" and "end" are textiter at start and end of line.
gtk_text_iter_set_line_offset (start, 0);
gtk_text_iter_forward_to_line_end (end);
line = gtk_text_iter_get_text (start, end);
gtk_clipboard_set_text (clipboard, line, -1);
And upon execution, Im getting the following error messages.
Gtk[27786]: CRITICAL: gtk_text_iter_set_line_offset: assertion 'iter != NULL' failed
Gtk[27786]: CRITICAL: gtk_text_iter_forward_to_line_end: assertion 'iter != NULL' failed
Gtk[27786]: CRITICAL: gtk_text_iter_get_text: assertion 'start != NULL' failed
Gtk[27786]: CRITICAL: gtk_clipboard_set_text: assertion 'text != NULL' failed
What is wrong with the code block? How can i resolve it?
Thanks all :)
You have probably got your iterators declared like GtkTextIter *start. Instead, according to the text widget conceptual overview in GTK's documentation, "GtkTextIter is a struct designed to be allocated on the stack; it's guaranteed to be copiable by value and never contain any heap-allocated data." This means you should not declare them as pointers:
GtkTextIter start, end;
// ...
gtk_text_iter_set_line_offset (&start, 0);
gtk_text_iter_forward_to_line_end (&end);
line = gtk_text_iter_get_text (&start, &end);
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'm getting some intermittent assertion failures when doing constrained Delaunay trianguation with the GNU Triangulated Surface Library. I've seen each of the following at different times:
Gts:ERROR:cdt.c:974:remove_intersected_vertex: code should not be reached
Gts:ERROR:cdt.c:896:remove_intersected_edge: assertion failed: (next)
Gts:ERROR:cdt.c:887:remove_intersected_edge: assertion failed: (o2 == 0.)
I've looked at cdt.c but all I've been able to figure out is that they're coming from calls to gts_delaunay_add_constraint.
Could someone explain what might be the problem with the constraints, that would cause these assertions to fail?
The assertion failures are happening when I try to do triangulation on a set of random vertices. It only happens, unfortunately, for large numbers of vertices and constraints, so it's hard to figure out a pattern for the failing inputs. The code that's using GTS needs to not crash even for bad input, so it would be nice to prevent these assertion failures, otherwise I'll have to disable the assertions.
Edit: Tried removing all intersecting constraints (stored in edges):
int numPossEdges = gts_fifo_size(edges);
GtsEdge **possEdges = malloc(numPossEdges * sizeof(GtsEdge *));
for (int i = 0; i < numPossEdges; ++i)
possEdges[i] = gts_fifo_pop(edges);
for (int i = 0; i < numPossEdges; ++i)
for (int j = 0; j < i && possEdges[i] != NULL; ++j)
if (possEdges[j] != NULL && GTS_IN == gts_segments_are_intersecting(&(possEdges[i]->segment), &(possEdges[j]->segment)))
possEdges[i] = NULL;
for (int i = 0; i < numPossEdges; ++i)
if (possEdges[i] != NULL)
gts_fifo_push(edges, possEdges[i]);
Still getting the same assertion failures.
If you're creating vertices and constraints completely randomly, I imagine you might be supplying constraint edges that intersect each other. In which case I would certainly expect the triangulation routines to complain.
The code that's using GTS needs to not crash even for bad input, so it
would be nice to prevent these assertion failures, otherwise I'll have
to disable the assertions.
I ended up writing a patch that causes GTS to (basically) throw an exception instead of halting when it hits an assertion failure. The patch is here.