genom3

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 :)

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.

I see!
I'll have a look.

I guess, we can close it. No?

Up to you :)

There is still no indication about what went wrong exactly when the
deserialization fails ...

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.