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

Tue Sep 6 11:45:10 UTC 2016

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 ()

Also please find attached valgrind output (libvirt-php_vlagrind.zip).

Thanks.

Fer

On mar, sep 6, 2016 at 12:59 , Michal Privoznik <mprivozn at redhat.com> 
wrote:
> On 05.09.2016 23:08, Fernando Casas Schössow wrote:
>>  Hi again Michal,
>> 
>>  I have more information to share.
>>  I think I can confirm that the patches are actually fixing the
>>  credentials problem and they are passed along.
>>  This is the content of test.log with libvirt-php output:
>> 
>>  [2016-09-05 22:06:05 libvirt-php/core ]: libvirt_connect: 
>> credentials
>>  index 2
>>  [2016-09-05 22:06:05 libvirt-php/core ]: libvirt_connect: 
>> credentials
>>  index 5
>>  [2016-09-05 22:06:05 libvirt-php/core ]: libvirt_connect: Found 2
>>  elements for credentials
>>  [2016-09-05 22:06:05 libvirt-php/core ]: 
>> libvirt_virConnectAuthCallback:
>>  cred 0, type 5, prompt Enter Administrator's password for 
>> 192.168.7.2
>>  challenge 192.168.7.2
>>  [2016-09-05 22:06:05 libvirt-php/core ]: 
>> libvirt_virConnectAuthCallback:
>>  result somepass (16)
>> 
>>  Of course then the process is crashing and the connection is 
>> aborted so
>>  I believe that the patches work fine (they fix the connection
>>  credentials not passed along issue) but once this is fixed the other
>>  problem is uncovered.
> 
> Cool, so at least that's confirmed. Can you please attach a debugger 
> to
> your php (or run php straight from it). Also, the stack trace is the
> result of 'backtrace' command in gdb, not strace (which is a system 
> call
> tracer).
> 
> $ gdb $(which php)
> (gdb) run test.php
> (gbd) backtrace
> 
> And while you're at it:
> $ valgrind --leak-check=full $(which php) test.php
> 
> Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160906/e7da36d3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvirt-php_vlagrind.zip
Type: application/zip
Size: 5478 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160906/e7da36d3/attachment-0001.zip>