On Thu, Oct 13, 2016 at 12:29 PM, David Pinkerton <dpinkert(a)redhat.com> wrote:
Good News.
I installed the fedora 24 version of python-dmidecode and was able to
successfully add the host to my cluster...
Thanks you to everyone who looked at this. I owe you a beer or at least
some reward points :-)
You owe us a rhel bug for dmidecode :-)
Program received signal SIGSEGV, Segmentation fault.
dmi_set_vendor (s=0x0) at src/dmioem.c:45
45 if(strcmp(s, "HP") == 0)
s is a null, cannot work with strcmp
(gdb) thread apply all bt full
Thread 1 (Thread 0x7ffff7feb740 (LWP 6318)):
#0 dmi_set_vendor (s=0x0) at src/dmioem.c:45
__s1 = 0x0
__result = <error reading variable __result (Cannot access
memory at address 0x0)>
#1 0x00007fffead5f66f in dmi_table (logp=logp@entry=0xaa70e0,
type=type@entry=1, base=<optimized out>, len=<optimized out>,
num=<optimized out>, ver=<optimized out>,
devmem=devmem@entry=0x7fffead645e0 "/dev/mem",
xmlnode=xmlnode@entry=0x6e5420) at src/dmidecode.c:4902
next = <optimized out>
h = {type = 0 '\000', length = 252 '\374', handle = 13, data =
0xa4f4aa ""}
It look like the code is trying to get the vendor name from type 0.
The fact that this leads to sending null vendor string is a second bug.
I believe dmidecode is missing this upstream patch:
https://github.com/nirs/dmidecode/commit/6e3a3f3cd36f633a56437b42e40d6769...
Nir
On Thu, Oct 13, 2016 at 7:28 PM, Martin Polednik
<mpolednik(a)redhat.com>
wrote:
>
> On 13/10/16 09:01 +0300, Dan Kenigsberg wrote:
>>
>> On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote:
>>>
>>> Nir,
>>>
>>> Looks like its crashing on the dmidecode system call.
>>>
>>> I've attached the output from gbd as well as a dmidecode text dump,
>>> dmidecode binary dump and each keywords run individually.
>>>
>>> >From the keywords it look like my dmi info is corrupted. I have
>>> download a
>>> AMI dmi editor but this only allows access to limited fields. Do you
>>> know
>>> another tools to rewrite the dmi info?
>>
>>
>> I don't. But whatever is inside your dmi, dmidecode must not crash.
>> Which version of python-dmidecode do you have installed?
>> Would you open a bug against it?
>
>
> This is really unfortunate - I've reproduced the issue with the
> attached dump and it's python-dmidecode that crashes. The issue is
> actually fixed upstream, but the version at least in RHEL does not
> contain the fix.
>
> RHEL version:
> python-dmidecode-3.10.13-11.el7.x86_64
>
> works with (actual upstream):
> python-dmidecode-3.12.2-1.el7.x86_64
> (actually it's ~6 line change in dmioem.c)
>
> VDSM output:
> # vdsClient 0 getVdsHardwareInfo
> systemFamily = 'To Be Filled By O.E.M.'
> systemManufacturer = 'Supermicro'
> systemProductName = 'H8DM8-2'
> systemSerialNumber = '1234567890'
> systemUUID = '00020003-0004-0005-0006-000700080009'
> systemVersion = '1234567890'
>
> Although the upstream version of python-dmidecode is able to deal with
> improper DMI tables, I can't say what else will/will not behave correctly.
>
> mpolednik
>
>
>> I believe that its maintainers would appriace a simple reproducer, that
>> does not involve ovirt or Vdsm. See if you can simplify the code in
>>
>> def __leafDict(d):
>> ret = {}
>> for k, v in d.iteritems():
>> if isinstance(v, dict):
>> ret.update(__leafDict(v))
>> else:
>> ret[k] = v
>> return ret
>>
>>
>> def getAllDmidecodeInfo():
>> import dmidecode
>>
>> myLeafDict = {}
>> for k in ('system', 'bios', 'cache',
'processor', 'chassis',
>> 'memory'):
>> myLeafDict[k] = __leafDict(getattr(dmidecode, k)())
>> return myLeafDict
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/users
--
David Pinkerton
Consultant
Red Hat Asia Pacific Pty. Ltd.
Level 11, Canberra House
40 Marcus Clarke Street
Canberra 2600 ACT
Mobile: +61-488-904-232
Email: david.pinkerton(a)redhat.com
Web:
http://apac.redhat.com/
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users