search

smich123 / open-zwave

Automatically exported from code.google.com/p/open-zwave
0 stars 0 forks source link

open-zwave r638 hangs on exit #176

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start the "cpp/example/linux/MiniOZW"
2. Let it run for e.g. 60-180 seconds
3. It will try to exit, but it hangs

In my example none of the nodes are discovered, they are physically to far 
away, but it doesn't matter if they are discovered or not (tried it on multiple 
systems)

What is the expected output? What do you see instead?
open-zwave not hanging at exit

What version of the product are you using? On what operating system?
open-zwave r638, LUbuntu 10.04LTS 32-bits

Please include the file OZW_Log.txt from your program. Make sure the file
zwcfg*.xml is NOT present.

Please provide any additional information below.

I forced a core dump when it is hanging, the backtrace is as follows:
(gdb) bt
#0  0x003a0422 in __kernel_vsyscall ()
#1  0x00679af9 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x0067513b in _L_lock_748 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0x00674f61 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4  0x080b803c in OpenZWave::MutexImpl::Lock (this=0x8d7dcb8, _bWait=true) at 
../../src/platform/unix/MutexImpl.cpp:82
#5  0x080b561a in OpenZWave::Mutex::Lock (this=0x8d74418, _bWait=true) at 
../../src/platform/Mutex.cpp:66
#6  0x080c460f in OpenZWave::Driver::isPolled (this=0x8d73c70, _valueId=...) at 
../../src/Driver.cpp:3781
#7  0x0805c928 in ~Node (this=0x8d76350, __in_chrg=<value optimized out>) at 
../../src/Node.cpp:174
#8  0x080bb39a in ~Driver (this=0x8d73c70, __in_chrg=<value optimized out>) at 
../../src/Driver.cpp:266
#9  0x08051af4 in OpenZWave::Manager::RemoveDriver (this=0x8d6ccc8, 
_controllerPath=...) at ../../src/Manager.cpp:293
#10 0x0804f38c in main (argc=1, argv=0xbff30994) at Main.cpp:366

Original issue reported on code.google.com by uAle...@gmail.com on 10 Feb 2013 at 6:25

Attachments:

GoogleCodeExporter commented 9 years ago 
Already reported this in Issue 167
Easiest fix: Move the ReleaseMutex statements in Driver::~Driver to the end of 
the function.

Original comment by matthias...@googlemail.com on 10 Feb 2013 at 6:39

GoogleCodeExporter commented 9 years ago 
The issue 167 description looks to be different, but can have a the same 
root-cause.

Original comment by uAle...@gmail.com on 10 Feb 2013 at 6:48

GoogleCodeExporter commented 9 years ago 
Jup, but the fix for 167 caused this new problem ;)

Original comment by matthias...@googlemail.com on 10 Feb 2013 at 7:02

GoogleCodeExporter commented 9 years ago 
Getting the destructor order correct has been a consistent challenge. Just 
another case. Please try r639. Also adding comments and fixes to old fixed 
issues makes it hard for tracking. Opening a new issue like this one helps 
keeps things straight. Thanks for reporting these bugs.

Original comment by glsatz on 10 Feb 2013 at 8:16

GoogleCodeExporter commented 9 years ago 
Greg, I can confirm it is fixed in r639. Thanks again for the quick fix.

Original comment by uAle...@gmail.com on 10 Feb 2013 at 8:23

GoogleCodeExporter commented 9 years ago 
Thanks to Matthias Einwag for quickly pin pointing this issue.

Original comment by glsatz on 10 Feb 2013 at 8:59