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