Project

General

Profile

Feature #144

make genom_reserve_sequence more "verbose" when unhappy...

Added by François Ingrand about 1 year ago. Updated 11 months ago.

Status:
Closed
Priority:
Normal

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

signature.asc (833 Bytes) signature.asc François Ingrand, 2018-05-08 09:57

Associated revisions

Revision 5cf9b1ad (diff)
Added by Anthony Mallet about 1 year ago

Fix genom_sequence_reserve() called with 0 length

As malloc(0) is undefined (it can return NULL), one must treat allocation of a
0-length sequence specially.

History

#1

Updated by Anthony Mallet about 1 year 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 :)

#2

Updated by François Ingrand about 1 year 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.

#3

Updated by Anthony Mallet about 1 year ago

I see!
I'll have a look.

#4

Updated by François Ingrand 11 months ago

  • Status changed from New to Closed

I had this pb because of the malloc/realloc pb fixed in:

https://git.openrobots.org/projects/genom3/repository/revisions/5cf9b1ad4b4381a6fa6687e82e75060eb9844a53

I guess, we can close it. No?

#5

Updated by Anthony Mallet 11 months 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 ...

#6

Updated by François Ingrand 11 months ago

On 07 May 2018, at 22:04, Anthony Mallet <> 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?

#7

Updated by Anthony Mallet 11 months 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.

Also available in: Atom PDF