Further follow up on this issue — the COM_write_once failure seems spurious as
it only happens while stepping in the debugger. The later failure, however,
happens debugging or not. The select() call in tcp_read() is always failing
with an invalid argument, which looks like the file_descriptor has become
invalid between here and where it is opened shortly before. There is then a
cascading series of failures in the retry attempts, which aren’t very effective
as retries because they don’t handle the failed file_descriptor.
I would be suspicious of the rest of my program (which uses libuv and
civetweb), except that a standalone test program that only issues OWCAPI calls
in a minimal sequence also fails the same way. The owserver daemon, however,
does *not* fail.
The call stack at the failure point is:
tcp_read
telnet_read
COM_read
OWServer_Enet_read
OWServer_Enet_reopen
OWServer_Enet_reopen
OWServer_Enet_setup
OWServer_Enet_detect
SetupSingleInboundConnection
SetupInboundConnections
LibStart
setup_from_args
API_init_args
OW_init_args_both
OW_init_args
<calling program>
Any suggestions from more experienced OWFS users/developers?
> On Nov 10, 2017, at 7:02 PM, Andrew Brownsword
> <andrew.e.brownsw...@gmail.com> wrote:
>
> With the LibStart() call inserted (or using OW_init without the program name
> as a first argument), I can now step into the connection process.
> Unfortunately it fails in COM_write_once during a write() call. It is trying
> to write 50 bytes, and the write of the first pipe causes a SIGPIPE exception
> if I’m stepping through the code. If I let it run past it still fails
> somewhere with a failure to talk to the enet device.
>
>
>> On Nov 10, 2017, at 11:00 AM, Andrew Brownsword
>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>> wrote:
>>
>> I noticed that OW_init_args() doesn’t appear to call LibStart(NULL), while
>> OW_init() does. Is this by design? By inserting the LibStart(NULL) call
>> things proceed much further, and although it is still having issues
>> communicating with my enet device, at least now it is trying!
>>
>>
>>> On Nov 10, 2017, at 9:38 AM, Andrew Brownsword
>>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>>
>>> wrote:
>>>
>>> Thanks Justin and Jan, your replies help enormously. I can now step into
>>> the libowcapi code, at least, and therefore can make forward progress.
>>> Might I suggest that the libowcapi man page(s) be supplemented to contain
>>> this information as well? I couldn’t find it.
>>>
>>> The first thing I discovered was that the reason my program had no bus.0/
>>> entry was because I neglected to include a first argument that is the
>>> program name. My —enet= option got eaten and ignored as a result… a bit
>>> surprising but easily fixed. So now my program and the test program fail
>>> in the same way.
>>>
>>> The second thing noticed (and I’ve only started to dive deeper) is it
>>> doesn’t appear that a thread was spawned during the init and the OW_get
>>> sees a NULL pin pointer, sets a badthread flag and basically bails at that
>>> point. Can anyone illuminate where the thread is supposed to get spawned?
>>>
>>>
>>>> On Nov 8, 2017, at 4:37 PM, Justin Brewer <justin.bre...@vertivco.com
>>>> <mailto:justin.bre...@vertivco.com>> wrote:
>>>>
>>>> On Wed, Nov 08, 2017 at 01:51:49PM -0800, Andrew Brownsword wrote:
>>>>> Nothing but crickets — is anyone out there?
>>>>>
>>>>> I’ve been poking at the code to try and figure out how to enable my
>>>>> debugger to step into the libowcapi/libow code, but the make process is
>>>>> obscure enough that some advice would be welcome...
>>>>
>>>> If you're working from a clean git clone, I use this for working with just
>>>> owcapi:
>>>>
>>>> $ autoreconf -i
>>>> $ ./configure CFLAGS='-g -O0' --prefix=$HOME/opt/owfs
>>>> --disable-{zero,ow{perl,python,php,tcl}}
>>>> $ make
>>>> $ make -k install
>>>>
>>>> This lets me ignore most of the language binding dependencies, and ignore
>>>> some hardcoded install paths.
>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Oct 31, 2017, at 3:11 PM, Andrew Brownsword
>>>>>> <andrew.e.brownsw...@gmail.com <mailto:andrew.e.brownsw...@gmail.com>>
>>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I have an EDS ETH-OWSERVER v2, and I am trying to talk to it using the
>>>>>> owcapi library. The init with arts function returns success but when I
>>>>>> try to OW_get, I don’t see any buses or sensors (just the meta
>>>>>> directories). If I run owserver, it sees the enet device and it’s 3
>>>>>> buses and 22 sensors just fine. I ran a simple owcapi test program and
>>>>>> it sees one bus and zero sensors.
>>>>>>
>>>>>> My program is multi-threaded and the OW_get will be called from a
>>>>>> different thread than the init (but correctly ordered). As for the test
>>>>>> program, it is just the init and then a get of root.
>>>>>>
>>>>>> I’m using the latest release and running on either an Ubuntu ARM host or
>>>>>> on OSX... same behavior either way.
>>>>
>>>> I have been working on some issues I've found in libow, and have seen
>>>> similair symptoms. There's some race conditions that, if it doesn't
>>>> outright crash, causes random failures elsewhere. I have a patch that
>>>> resolves these issues here:
>>>>
>>>> https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch
>>>>
>>>> <https://gitlab.com/justinbrewer/owfs/commit/0234a2cecb56d0b6ca4d20a6100a2d2b2ba6bffb.patch>
>>>>
>>>> I was planning on submitting a pull request in the next day or so, but I
>>>> think this patch help you.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>>> http://sdm.link/slashdot <http://sdm.link/slashdot>
>>>> _______________________________________________
>>>> Owfs-developers mailing list
>>>> Owfs-developers@lists.sourceforge.net
>>>> <mailto:Owfs-developers@lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>> <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
