Feature #144
closedmake genom_reserve_sequence more "verbose" when unhappy...
Description
I had a port with a sequence which I did not properly "initialize" (propbably forgot to set _length). I had a :
SafetyPilot: cannot read inport Scan contents
Message... but no clue where to look at... in the
genom_deserialize_t_laser_LaserScan
call from:
b = posterAddr(ph->id);
if (b) {
max = -1;
s = genom_deserialize_t_laser_LaserScan(
&b, &max, &(ph->buffer));
} else s = ERROR;
posterGive(ph->id);
if (s) {
genom_log_warn(0, "cannot read inport Scan contents");
return genom_serialization(self);
}
return genom_ok;
Printing something on stderr? or an assert? or may be nothing... I am just annoyed it took me half a day to find it. ;-)
Files
Updated by Anthony Mallet over 6 years ago
The deserialization already raises an exception, and a message is
printed on stderr. What else could it do? :)
You should have checked the returned value in your code. The
deserialization will update the storage for variable length sequences,
so you don't have to initialize any length or anything (just pass a
"valid" object, even with 0 length).
As far as genom_sequence_reserve() is concerned, if returns non-zero
on error with errno set appropriately. And errno can only be ENOMEM.
If a call to this function fails inside the deserialization code
itself (i.e. not in your code), there is already an "out of memory"
assertion.
So I don't know what to do :)
Updated by François Félix Ingrand over 6 years ago
Anthony Mallet wrote:
The deserialization already raises an exception, and a message is
printed on stderr. What else could it do? :)
Tell me where in the deserialization it went wrong. LaserScan is a rather large structure, with two float sequences...I think I had a pb because one of the sequence (which I created) did not have the _length set (so it must have been garbage).
You should have checked the returned value in your code. The
deserialization will update the storage for variable length sequences,
so you don't have to initialize any length or anything (just pass a
"valid" object, even with 0 length).
Sure, but I created the port in module A with a missing _length and the module B reading it reported this error... still I was able to print the port in eltclsh (so I thought it was right). It is only when I realized that one of the sequence was empty (but should not) that I figured out that _length was missing from the initial creation.
As far as genom_sequence_reserve() is concerned, if returns non-zero
on error with errno set appropriately. And errno can only be ENOMEM.If a call to this function fails inside the deserialization code
itself (i.e. not in your code), there is already an "out of memory"
assertion.So I don't know what to do :)
Clearly, the code figured out that there was a pb (it printed the error message)... I am just checking if it is possible to be more specific as where the error occurred inside the deserialization of the port.
Updated by François Félix Ingrand almost 6 years ago
- Status changed from New to Closed
I had this pb because of the malloc/realloc pb fixed in:
I guess, we can close it. No?
Updated by Anthony Mallet almost 6 years ago
I guess, we can close it. No?
Up to you :)
There is still no indication about what went wrong exactly when the
deserialization fails ...
Updated by François Félix Ingrand almost 6 years ago
- File signature.asc signature.asc added
On 07 May 2018, at 22:04, Anthony Mallet <anthony.mallet@laas.fr> wrote:
Issue #144 has been updated by Anthony Mallet.
I guess, we can close it. No?
Up to you :)
There is still no indication about what went wrong exactly when the
deserialization fails …
It failed because the genom_reserve_sequence returned one time the result of free(0) and one time malloc(0)… or something like that.
This was the “visible” consequence of the bug we fixed in 5cf9b1ad4b4381a6fa6687e82e75060eb9844a53
no?
Updated by Anthony Mallet almost 6 years ago
On Tuesday 8 May 2018, at 09:57, François Ingrand wrote:
It failed because the genom_reserve_sequence returned one time the
result of free(0) and one time malloc(0)… or something like that.
Yes. The underlying issue is fixed.
However, the initial point of this issue was to report where the
failure was. As you said:
“cannot read inport Scan contents... but no clue where to look at...”
So I think this still makes sense to try to report where the
deserialization failed, when it failed. But it's definititely not high
priority.