roshbaik2 / open-zwave

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

Always get a segfault after delete zwcfg!!!! #400

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

I had my network running fine until I decided to delete my zwcfg after the last 
update.

It turns out that my application never worked again, everytime the network is 
starting I get a segmentation fault and it dies...

Here goes the gdb stacktrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7090b70 (LWP 9685)]
0xb74a4cf8 in 
std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*) () 
from /usr/lib/i386-linux-gnu/libstdc++.so.6
(gdb) backtrace
#0  0xb74a4cf8 in 
std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*) () 
from /usr/lib/i386-linux-gnu/libstdc++.so.6
#1  0xb7646468 in 
OpenZWave::Driver::QueueNotification(OpenZWave::Notification*) ()
#2  0xb7615d10 in OpenZWave::ManufacturerSpecific::HandleMsg(unsigned char 
const*, unsigned int, unsigned int) ()
#3  0xb75ef8ed in OpenZWave::Node::ApplicationCommandHandler(unsigned char 
const*) ()
#4  0xb76434e2 in 
OpenZWave::Driver::HandleApplicationCommandHandlerRequest(unsigned char*) ()
#5  0xb764e613 in OpenZWave::Driver::ProcessMsg(unsigned char*) ()
#6  0xb764f58a in OpenZWave::Driver::ReadMsg() ()
#7  0xb764f94b in OpenZWave::Driver::DriverThreadProc(OpenZWave::Event*) ()
#8  0xb764fb47 in OpenZWave::Driver::DriverThreadEntryPoint(OpenZWave::Event*, 
void*) ()
#9  0xb76602be in OpenZWave::ThreadImpl::Run() () 
#10 0xb76602fb in OpenZWave::ThreadImpl::ThreadProc(void*) ()
#11 0xb7fb4c39 in start_thread () from 
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#12 0xb7ed978e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6

I have polycontrol doorlock and keypad secured devices, one ehk switch and 1 
aeon labs multi sensor...

Original issue reported on code.google.com by santal.m...@gmail.com on 20 Nov 2014 at 11:48

GoogleCodeExporter commented 9 years ago
Hi,

I compiled the openzwave in debug mode and tried to do some debug. Here is the 
result:

Breakpoint 1, OpenZWave::Driver::QueueNotification (this=0x0, 
_notification=0x4ed110)
    at /root/Projects/rpihome/rpiHomeLogic/protocols/zwave/openzwave/cpp/src/Driver.cpp:5515
5515            m_notifications.push_back( _notification );

1: _notification = (OpenZWave::Notification *) 0x4ed110

(gdb) p /s *_notification

$36 = {m_type = OpenZWave::Notification::Type_NodeNaming, m_valueId = {
    m_id = 150994944, m_id1 = 0, m_homeId = 6069680}, m_byte = 0 '\000'}
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xb5fcdd50 in 
std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_ base*) () 
from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(gdb) backtrace
#0  0xb5fcdd50 in 
std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*) () 
from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#1  0xb61716dc in std::list<OpenZWave::Notification*, 
std::allocator<OpenZWave::Notification*> >::_M_insert (this=0x520, 
__position=...,__x=@0xb5f1e7f8: 0x4ed110) at 
/usr/include/c++/4.6/bits/stl_list.h:1516
#2  0xb6170d94 in std::list<OpenZWave::Notification*, 
std::allocator<OpenZWave::Notification*> >::push_back (this=0x520, 
__x=@0xb5f1e7f8: 0x4ed110)
    at /usr/include/c++/4.6/bits/stl_list.h:988
#3  0xb616cb7c in OpenZWave::Driver::QueueNotification 
(this=0x0,_notification=0x4ed110)
    at /root/Projects/rpihome/rpiHomeLogic/protocols/zwave/openzwave/cpp/src/Driver.cpp:5515
#4  0xb618d644 in OpenZWave::ManufacturerSpecific::HandleMsg (this=0x518c08, 
_data=0xb5f1e8f8 "\005", _length=8, _instance=1)
    at /root/Projects/rpihome/rpiHomeLogic/protocols/zwave/openzwave/cpp/src/command_classes/ManufacturerSpecific.cpp:210
#5  0xb6177724 in OpenZWave::Node::ApplicationCommandHandler 
(this=0x5b4b10,_data=0xb5f1e8f2 "")
    at /root/Projects/rpihome/rpiHomeLogic/protocols/zwave/openzwave/cpp/src/Node.cpp:1531
#6  0xb6167074 in OpenZWave::Driver::HandleApplicationCommandHandlerRequest 
(this=0x5b2a48, _data=0xb5f1e8f2 "")
    at /root/Projects/rpihome/rpiHomeLogic/protocols/zwave/openzwave/cpp/src/Driver.cpp:3356
#7  0xb61630bc in OpenZWave::Driver::ProcessMsg (this=0x5b2a48,_data=0xb5f1e8f2 
"")
    at /root/Projects/rpihome/rpiHomeLogic/protocols/zwave/openzwave/cpp/src/Dri
#8  0xb6161fd8 in OpenZWave::Driver::ReadMsg (this=0x5b2a48)

Original comment by santal.m...@gmail.com on 22 Nov 2014 at 9:07

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Any change you can enable debug with OZW_Log.txt? That should give some 
information what came in from the z-wave controller.

Original comment by uAle...@gmail.com on 22 Nov 2014 at 9:28

GoogleCodeExporter commented 9 years ago
The stack trace looks interesting, the m_id should be part of the nodeid and 
m_id1 should be the instance. Nodeid is inside the m_id, which looks in your 
example 0 and instance normally 1 and up. Some bogus data is coming from 
somewhere :-(

Original comment by uAle...@gmail.com on 22 Nov 2014 at 9:53

GoogleCodeExporter commented 9 years ago
Hi, thanks a lot for the feedback I'm getting desperate here....

Ok I will send you the OZW_Log.txt

Original comment by santal.m...@gmail.com on 22 Nov 2014 at 10:23

GoogleCodeExporter commented 9 years ago
Here goes the log

Original comment by santal.m...@gmail.com on 22 Nov 2014 at 10:41

Attachments:

GoogleCodeExporter commented 9 years ago
First things first, the following config files don't exist in the open-zwave 
svn:
config/polycontrol/doorlock.xml
config/ehk/bridgekeeper.xml

The doorlock seems to be ok'ish, but the application/lib stopped at the 
bridgekeeper.

Can you share these configs with us?

Original comment by uAle...@gmail.com on 23 Nov 2014 at 8:15

GoogleCodeExporter commented 9 years ago
I already created a post with that info

By the way, bridgekeeper is wrong I have rename it to switchkeeper
Note That I removed all the command classes that where causing failed attempts 
because my network always get slow caused by failed messages, (as described on 
the below link too)

The other devices are in this link

https://groups.google.com/forum/#!topic/openzwave/QIVv_ovkQDM

Original comment by santal.m...@gmail.com on 23 Nov 2014 at 1:16

Attachments:

GoogleCodeExporter commented 9 years ago
The config files are a little bit confusing, but in the google groups i see 
invalid data:

<CommandClass id="32" action="remove"/>
<CommandClass id="133" action="remove"/>
<CommandClass id="2" action="remove"/>

There is no commandclass "2". Not sure it can crash the system.

Also in your doorlock, you remove commandclass 133 ... and later in the file, 
you add it again?

Good test is to remove all device specific configs and start open-zwave without 
them ... see if it still crashes or not.

Original comment by uAle...@gmail.com on 23 Nov 2014 at 1:25

GoogleCodeExporter commented 9 years ago
Ok,

I did the following, I managed to reset the ZStick... all worked fine... Guess 
that somehow the zstick had something wrong in it.

I am going to take a good look at those files as you said

Now my only problem are those messages with failed attempts I need to rid of.

Any hint to don't have my network all clogged with those failling messages?

Isn't there a way to remove those attempts, like I send a message if it 
fails... it fails no retries?

Original comment by santal.m...@gmail.com on 23 Nov 2014 at 2:24

GoogleCodeExporter commented 9 years ago
I updated the manufacturer.xml and modified your device config xmls, can you 
try the attached files? It should remove most of the timeouts.

Just untar/gunzip them in the directory.

If you can confirm these works correctly, i will add to them to the open-zwave 
library files.

Original comment by uAle...@gmail.com on 23 Nov 2014 at 6:24

Attachments:

GoogleCodeExporter commented 9 years ago
Ok here is the status...

I still have a lot of hangs and I lost the usercodes values from the keypad.

Also I find there is a strange behaviour on AeonLabs MultiSensor... It reports 
the sensor values 3 times each

I will send you a log

Original comment by santal.m...@gmail.com on 26 Nov 2014 at 9:04

Attachments: