2015-09-22 0:09 GMT+02:00 Jan Kandziora <j...@gmx.de>: > Am 21.09.2015 um 23:29 schrieb Jan Kandziora: > > > > Fortunately, I can narrow these crashes down to undefined behaviour > > > > * when a property in the config file is of for example "u" type > > * and the script called does not return any data, or something which > > cannot be parsed as configured. > > > > One could argue "okay, it's configured as unsigned so it should always > > return an unsigned integer" but calling the script may fail for some > > reason and the last thing we want in this case is having owserver crash. > > > > > > I'm currently thinking how to fix this. > > > Paul, you have to help me here. For some odd reason FS_r_external() is > not allowed to fail. > > If I change module/owlib/src/c/ow_read_external.c:52 into > return 0 ; > > all is okay. If I place "return -ENOENT ;" there, I get the owserver > crash always when accessing an external node. Same as with the original > "return zoe ;" when the node returns -EINVAL. The problem is connected > to the error condition, not to the bad data.
Jan, I have to admit, that currently I don't have any devel host to test this. But reading your observation I wonder, if this would fail for other sensor types as well... What about trying to patch the fake adapter or maybe any other to always return -EINVAL - does owserver crash as well?
------------------------------------------------------------------------------
_______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
