Hi,
good to know I was partly correct! The thought occured to me after
sending the previous mail, that Linux may just ignore errenous destroy
calls. Far more likely reason than nobody using owserver.. :)
>From FreeBSD manpage:
The pthread_mutex_destroy() function will fail if:
[EINVAL] The value specified by mutex is invalid.
[EBUSY] Mutex is locked by another thread.
Linux (CentOS 6) manpage says mostly the same on result codes, but also:
"the results of otherwise referencing the object after it has been
destroyed are undefined".
I guess "undefined" in this case means "not actually giving EINVAL".
Regarding errors, it's your code and your call, and there might be
reasons I'm unaware of which warrants this behavior. But IMO it's odd to
NOT report fatal errors in any way by default.
If it was my call (and with my limited owfs knowhow) I'd go for two changes:
a) Set fatal_debug to 1 by default
b) Report fatal errors even if not compiled with DEBUG
Regarding your other post (which is in the digest, which I have now
turned off so I can reply properly...), two versions should be fine as
long as the library does not use any shared memory stuff, I think?
When setting LD_LIBRARY_PATH before executing the binary, it should only
use the new library:
export LD_LIBRARY_PATH=/usr/ports/comms/owfs/work/stage/usr/local/lib
$ ldd
./usr/local/bin/owserver
./usr/local/bin/owserver:
libow-2.9.so.3 =>
/usr/ports/comms/owfs/work/stage/usr/local/lib/libow-2.9.so.3 (0x80064c000)
libusb.so.2 => /usr/lib/libusb.so.2 (0x800855000)
libm.so.5 => /lib/libm.so.5 (0x800967000)
libc.so.7 => /lib/libc.so.7 (0x800a87000)
libthr.so.3 => /lib/libthr.so.3 (0x800cca000)
No reference to the system-wide installed library. But again, I might be
unaware of some internals in OWFS. It seems to work fine running it like
this now anyhow.
Johan
On 4/3/14 03:25 , Paul Alfille wrote:
> Nice sleuthing! Thank you!
>
> You're right, the mutex should be initialized only once, in handler.c
> And destroyed there as well. The mutex is correctly used in multiple
> locations, however.
>
> I wonder if the double destroy is handled differently in FreeBSD?
> owserver didn't crash under linux.
>
> I'm tempted to leave the error handling alone, unless you wish otherwise.
>
> Paul Alfille
>
> The error is fixed in the CVS and will be fixed in the next release.
>
>
> On Wed, Apr 2, 2014 at 2:55 PM, Johan Ström <jo...@stromnet.se
> <mailto:jo...@stromnet.se>> wrote:
>
> Hello again,
>
> did some more debugging now and I have found the problem! Or at
> least I
> think? From what I gather, everyone running 2.9p3 owserver would have
> this crash... Which I would hope is at least some part of some release
> test process? :)
>
> It took some time to find the option --fatal_debug, after
> wondering why
> nothing was logged when the "fatal" error occurred, I digged the
> src and
> found this option (would it not make sense to make this default ON?).
> Anyhow, the following error showed up:
>
> FATAL ERROR: handler.c:(139) mutex_destroy failed rc=22 [Invalid
> argument]
>
> One addition to 2.9p3 is to exit on fatal errors (ref 1), which is
> whats
> happening here.
> On my old 2.9p1 installation, I started with --fatal_debug, and
> indeed,
> the same errors gets printed after every request, but owserver
> continues
> to work.
>
> So, what's causing this? It boils down to owserver/src/c/handler.c and
> owserver/src/c/loop.c trying to initialize/destroy the same mutex,
> hd.to_client.
>
> handler.c first inits the mutex, then it calls SingleHandler() ->
> PingLoop().
> In loop.c's PingLoop, we call LoopSetup(), which inits the *same*
> mutex
> varaible.
> When the request is done, LoopCleanup() is called which destroys the
> mutex created in the loop.
> Back in Handler, we finally try to destroy the mutex, which is already
> destroyed. And this is where we crash.
>
> In 2.9p1 the program goes on happily, except the leaked mutex which is
> never destroyed. (This is probably one of the causes my owserver seems
> to grow in memory after running for loong time..).
>
> So.. either I have missed something, or no-one has tried owserver with
> 2.9p3?
>
> Not sure about what the proper fix would be, but removing the mutex
> init/destroy in LoopSetup/Cleanup solves the crashing problem at least
> (not sure about side effects).
> In addition, I noticed SingleHandler did not lock while doing the
> optional call to PingClient(), but might not matter?
>
>
>
> Best regards
> Johan
>
> 1) 2.9p3 patch to exit on fatal errors:
> If debug is off:
>
> http://owfs.cvs.sourceforge.net/viewvc/owfs/owfs/module/owlib/src/include/ow_debug.h?r1=1.31&r2=1.32
> If debug is on:
>
> http://owfs.cvs.sourceforge.net/viewvc/owfs/owfs/module/owlib/src/c/error.c?r1=1.41&r2=1.42
> if debug is on)
>
>
> On 4/2/14 07:42 , Johan Ström wrote:
> > Hi,
> >
> > I'm testing the 2.9p3 release on FreeBSD 8.4. I'm currently running
> > 2.9p1 without problems, but with p3 it seems the owserver want's
> to exit
> > as soon as it has served a single request?
> >
> > Running my main owserver (2.9p1) on port 4304, starting the p3
> server on
> > 4305:
> >
> > $ export
> LD_LIBRARY_PATH=/usr/ports/comms/owfs/work/stage/usr/local/lib
> > $ /usr/ports/comms/owfs/work/stage/usr/local/bin/owserver --debug
> > --foreground -s localhost:4304 -p 4305
> > DEBUG MODE
> > libow version:
> > 2.9p3
> > DEBUG: ow_daemon.c:(166) main thread id = 34374435264
> > CALL: ow_parsename.c:(99) path=[]
> > DEBUG: owlib.c:(81) Globals temp limits 0C 100C (for
> simulated adapters)
> > DEBUG: ow_net_client.c:(85) IP address=[localhost] port=[4304]
> > CONNECT: ow_zero.c:(145) Zeroconf and/or Multithreading are not
> enabled
> >
> > (executing owdir -s localhost:4305 /system )
> >
> > DEBUG: ow_tcp_read.c:(64) attempt 24 bytes Time: 10.000000
> seconds
> > DEBUG: ow_tcp_read.c:(114) read: 24 - 0 = 24
> > DEBUG: from_client.c:(67) FromClient payload=8 size=0 type=7
> sg=0x10A
> > offset=0
> > DEBUG: from_client.c:(75) FromClient (no servermessage) payload=8
> > size=0 type=7 controlflags=0x10A offset=0
> > DEBUG: ow_tcp_read.c:(64) attempt 8 bytes Time: 10.000000 seconds
> > DEBUG: ow_tcp_read.c:(114) read: 8 - 0 = 8
> > DEBUG: handler.c:(153) START handler /system
> > CALL: data.c:(104) DataHandler: parse path=/system
> > DEBUG: ow_parseobject.c:(164) /system
> > CALL: ow_parsename.c:(99) path=[/system]
> > CALL: data.c:(164) Directory message (all at once)
> > DEBUG: dirall.c:(66) OWSERVER Dir-All SpecifiedBus=0 path =
> /system
> > DEBUG: ow_dir.c:(76) path=/system
> > CALL: ow_dir.c:(100) path=/system
> > DEBUG: ow_dir.c:(796) called on /system
> > CALL: ow_parsename.c:(99) path=[/system/configuration]
> > DEBUG: ow_parsename.c:(62) /system/configuration
> > CALL: ow_parsename.c:(99) path=[/system/connections]
> > DEBUG: ow_parsename.c:(62) /system/connections
> > CALL: ow_parsename.c:(99) path=[/system/process]
> > DEBUG: ow_parsename.c:(62) /system/process
> > DEBUG: ow_dir.c:(195) ret=0
> > DEBUG: ow_parsename.c:(62) /system
> > DEBUG: data.c:(194) DataHandler: FS_ParsedName_destroy done
> > DEBUG: data.c:(208) DataHandler: cm.ret=0
> > DEBUG: to_client.c:(67) payload=58 size=57, ret=0, sg=0x10A
> offset=0
> > DEBUG: data.c:(227) Finished with client request
> > DEBUG: handler.c:(135) OWSERVER handler done
> > $ echo $?
> > 1
> > $
> >
> > The same thing happens if I do a owdir on / (it does properly
> list all
> > my nodes).
> > Using the p1 binary, the above works as expected (i.e. not exiting).
> > I have not tested p2. I have no extra patches.
> >
> > Any ideas?
> >
> > Best regards
> > Johan
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
