My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 59: Segfault for list config param in HSM100
1 person starred this issue and may be notified of changes. Back to list
Status:  Duplicate
Closed:  Dec 2012

Sign in to add a comment
Project Member Reported by, Feb 11, 2012
I'm using py-openzwave with the latest r426, and I'm getting a Segmentation fault in Manager::GetValueListSelection when OZW reads the "LED ON/OFF" config parameter (type="list") from my HSM100:
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7adfb70 (LWP 3810)]
0x00130416 in __kernel_vsyscall ()
(gdb) bt
#0  0x00130416 in __kernel_vsyscall ()
#1  0x003b2c8f in raise () from /lib/i386-linux-gnu/
#2  0x003b62b5 in abort () from /lib/i386-linux-gnu/
#3  0x008304ed in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/i386-linux-gnu/
#4  0x0082e283 in ?? () from /usr/lib/i386-linux-gnu/
#5  0x0082e2bf in std::terminate() ()
   from /usr/lib/i386-linux-gnu/
#6  0x0082e40e in __cxa_throw () from /usr/lib/i386-linux-gnu/
#7  0x007d1bb3 in std::__throw_length_error(char const*) ()
   from /usr/lib/i386-linux-gnu/
#8  0x00813aa2 in std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) () from /usr/lib/i386-linux-gnu/
#9  0x00814d7f in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) () from /usr/lib/i386-linux-gnu/
#10 0x00815710 in std::string::assign(std::string const&) ()
   from /usr/lib/i386-linux-gnu/
#11 0x00815773 in std::string::operator=(std::string const&) ()
   from /usr/lib/i386-linux-gnu/
#12 0x006bad18 in OpenZWave::Manager::GetValueListSelection (this=0x85443a8, 
    _id=..., o_value=0xb7adf214) at ../../src/Manager.cpp:1779
#13 0x006b5d94 in __pyx_f_9openzwave_addValueId (__pyx_v_n=<optimized out>, 
    __pyx_v_v=...) at openzwave.cpp:1731
#14 __pyx_f_9openzwave_callback (__pyx_v__notification=0x1, __pyx_v__context=
    0x0) at openzwave.cpp:2096
#15 0x006bc5ff in OpenZWave::Manager::NotifyWatchers (this=0x85443a8, 
    _notification=0x8c017e8) at ../../src/Manager.cpp:2724
#16 0x00713663 in OpenZWave::Driver::NotifyWatchers (this=0x8b86ac8)
    at ../../src/Driver.cpp:4433
#17 0x0070999a in OpenZWave::Driver::DriverThreadProc (this=0x8b86ac8, 
    _exitEvent=0x8607310) at ../../src/Driver.cpp:346
#18 0x00709812 in OpenZWave::Driver::DriverThreadEntryPoint (_exitEvent=
    0x8607310, _context=0x8b86ac8) at ../../src/Driver.cpp:263
#19 0x0072209a in OpenZWave::ThreadImpl::Run (this=0x838a060)
    at ../../src/platform/unix/ThreadImpl.cpp:175
#20 0x0072205b in OpenZWave::ThreadImpl::ThreadProc (_pArg=0x838a060)
    at ../../src/platform/unix/ThreadImpl.cpp:160
#21 0x00137d31 in start_thread () from /lib/i386-linux-gnu/
#22 0x004570ce in clone () from /lib/i386-linux-gnu/
Backtrace stopped: Not enough registers or memory available to unwind further
(gdb) up
(gdb) up
#12 0x006bad18 in OpenZWave::Manager::GetValueListSelection (this=0x85443a8, 
    _id=..., o_value=0xb7adf214) at ../../src/Manager.cpp:1779
1779							*o_value = item.m_label;
(gdb) l
1774					if( ValueList* value = static_cast<ValueList*>( driver->GetValue( _id ) ) )
1775					{
1776						ValueList::Item const& item = value->GetItem();
1777						if( &item != NULL )
1778						{
1779							*o_value = item.m_label;
1780							res = true;
1781						}
1782						value->Release();
1783					}
(gdb) p value
$1 = (OpenZWave::ValueList *) 0x8a65288

There are a couple of things going on here. The segfault goes away if I remove the value="255" from the config. I suspect the way it's implemented it's expecting a list index and not a byte value, but either way I don't think bad input should be crashing the program. The segfault also goes away if I use the same config with r292, so it seems like there was a regression in the code.

Let me know if I can provide more information.
Dec 2, 2012
Project Member #1 glsatz
Is this still a problem in the current code?
Dec 2, 2012
Project Member #2
Haven't used it in a while, but I have no reason to believe it's still an issue. I'd have no objections if you wanted to close this issue.

Or if you like, you could try patching in the config from r426 to the latest code and see if you can get it to crash. I don't remember if you have to actually have an HSM100 for it to work...
Dec 3, 2012
Project Member #3 glsatz
This is the case of wishful optimism. We are thinking this problem has been resolved in other updates.
Status: Duplicate
Sign in to add a comment

Powered by Google Project Hosting