[libvirt] [libvirt-php] libvirt_connect not reading out credential info on 0.5.2

[Fernando Casas Schössow]

Thanks for the explanation Michal.

I will be looking forward the fix to try it. :)

On mar, sep 6, 2016 at 6:59 , Michal Privoznik <mprivozn at redhat.com> 
wrote:
> On 06.09.2016 13:45, Fernando Casas Schössow wrote:
>>  Thanks for the instructions since I'm not familiar with debugging 
>> as you
>>  probably guessed. :)
>> 
>>  Here you have gdb output:
>> 
>>  GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
>>  Copyright (C) 2013 Free Software Foundation, Inc.
>>  License GPLv3+: GNU GPL version 3 or later
>>  <http://gnu.org/licenses/gpl.html>
>>  This is free software: you are free to change and redistribute it.
>>  There is NO WARRANTY, to the extent permitted by law. Type "show 
>> copying"
>>  and "show warranty" for details.
>>  This GDB was configured as "x86_64-redhat-linux-gnu".
>>  For bug reporting instructions, please see:
>>  <http://www.gnu.org/software/gdb/bugs/>...
>>  Reading symbols from /usr/bin/php...Reading symbols from
>>  /usr/bin/php...(no debugging symbols found)...done.
>>  (no debugging symbols found)...done.
>>  Missing separate debuginfos, use: debuginfo-install
>>  php-cli-5.4.16-36.3.el7_2.x86_64
>>  (gdb) run /storage/lighttpd/wwwroot/libvirt.php
>>  Starting program: /usr/bin/php /storage/lighttpd/wwwroot/libvirt.php
>>  [Thread debugging using libthread_db enabled]
>>  Using host libthread_db library "/lib64/libthread_db.so.1".
>>  [New Thread 0x7fffe2ceb700 (LWP 31799)]
>>  [Thread 0x7fffe2ceb700 (LWP 31799) exited]
>>  PHP Warning: unlink(test.log): No such file or directory in
>>  /storage/lighttpd/wwwroot/libvirt.php on line 4
>> 
>>  Program received signal SIGSEGV, Segmentation fault.
>>  0x00007fffe9ad54a0 in virClassIsDerivedFrom () from 
>> /lib64/libvirt.so.0
>>  (gdb) backtrace
>>  #0 0x00007fffe9ad54a0 in virClassIsDerivedFrom () from 
>> /lib64/libvirt.so.0
>>  #1 0x00007fffe9b861ac in virDomainLookupByUUIDString () from
>>  /lib64/libvirt.so.0
>>  #2 0x00007fffea1e82c5 in generate_uuid () from
>>  /usr/lib64/php/modules/libvirt-php.so
>>  #3 0x00007fffe7d3385a in wsmc_create_request () from
>>  /lib64/libwsman_client.so.4
>>  #4 0x00007fffe7d3546f in wsmc_action_enumerate () from
>>  /lib64/libwsman_client.so.4
>>  #5 0x00007fffe9c8e34a in hypervEnumAndPull () from 
>> /lib64/libvirt.so.0
>>  #6 0x00007fffe9c8ee49 in hypervGetMsvmComputerSystemList () from
>>  /lib64/libvirt.so.0
>>  #7 0x00007fffe9c8dacd in hypervConnectOpen () from 
>> /lib64/libvirt.so.0
>>  #8 0x00007fffe9b82f39 in virConnectOpenInternal () from 
>> /lib64/libvirt.so.0
>>  #9 0x00007fffe9b845ce in virConnectOpenAuth () from 
>> /lib64/libvirt.so.0
>>  #10 0x00007fffea1e1190 in zif_libvirt_connect () from
>>  /usr/lib64/php/modules/libvirt-php.so
>>  #11 0x000055555586b57c in zend_do_fcall_common_helper_SPEC ()
>>  #12 0x00005555557e8527 in execute ()
>>  #13 0x00005555557c115f in zend_execute_scripts ()
>>  #14 0x0000555555760976 in php_execute_script ()
>>  #15 0x000055555586d598 in do_cli ()
>>  #16 0x000055555561a12e in main ()
> 
> 
> Ah, this is exactly what I needed. Well, we're doomed. There are two
> problems here.
> 
> The first one is: libvirt-php is exporting symbols that is shouldn't
> have. Like for instance generate_uuid which is clearly meant as an
> internal helper but because of our own bug (well, missing
> implementation) it is being exported. Thus, when linker is linking the
> libraries together it finds out that libwsman_client.so.4 needs
> generate_uuid symbol which it finds in libvirt-pgp.so instead of
> libwsman.so.1.0.0 (which is what libwsman devels intended).
> 
> objdump -T /usr/lib64/libwsman_client.so.4 | grep generate_uuid
> 0000000000000000      D  *UND*  0000000000000000              
> generate_uuid
> 
> bjdump -T /usr/lib64/php/modules/libvirt-php.so | grep generate
> 000000000002b660 g    DF .text  00000000000000ce  Base        
> generate_uuid
> 000000000002b590 g    DF .text  00000000000000cb  Base        
> generate_uuid_any
> 
> objdump -T /lib64/libwsman.so.1.0.0 | grep generate
> 000000000000e820 g    DF .text  00000000000001bd  Base        
> generate_uuid
> 000000000001f950 g    DF .text  000000000000005a  Base        
> wsman_generate_fault_buffer
> 000000000001f8c0 g    DF .text  0000000000000082  Base        
> wsman_generate_fault
> 
> The fix on our part is obvious.
> 
> The second problem is, libwsman devels should not really be using such
> generic names in their libraries. At least they need to prefix their
> public function names with wsman_ (see those other 'generate_fault'
> functions?).
> 
> I'll work on fix and let you test it - since the backtrace proof this
> is hyperv specific bug. That's why I was unable to reproduce it.
> 
> Thanks for the report!
> 
> Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160906/d1227f80/attachment-0001.htm>