hivex: Test failure for Perl, OCaml, Python bindings on sparc
by Hilko Bengen
On a Debian/unstable chroot environment on smetana.debian.org ("Linux
smetana 2.6.32-5-sparc64-smp #1 SMP Tue Mar 8 01:00:11 UTC 2011 sparc64
GNU/Linux") node_set_value and node_values fail with a "Bad address"
error, see below.
I am going to make an attempt at debugging this tonight, any advice
would be appreciated.
Cheers,
-Hilko
,----
| (sid)bengen@smetana:~/hivex.git/perl$ make check
| make check-TESTS
| make[1]: Entering directory `/home/bengen/hivex.git/perl'
| make -f Makefile-pl
| make[2]: Entering directory `/home/bengen/hivex.git/perl'
| make[2]: Leaving directory `/home/bengen/hivex.git/perl'
| make[2]: Entering directory `/home/bengen/hivex.git/perl'
| PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
| t/005-pod.t .............. skipped: Test::Pod 1.00 required for testing POD
| t/006-pod-coverage.t ..... skipped: Test::Pod::Coverage 1.00 required for testing POD
| t/010-load.t ............. ok
| t/020-open.t ............. ok
| t/021-close.t ............ ok
| t/200-write.t ............ ok
| t/210-setvalue.t ......... 1/11 node_set_value: Bad address at t/210-setvalue.t line 46.
| # Looks like you planned 11 tests but ran 5.
| # Looks like your test exited with 14 just after 5.
| t/210-setvalue.t ......... Dubious, test returned 14 (wstat 3584, 0xe00)
| Failed 6/11 subtests
| t/510-regedit-load.t ..... ok
| t/550-regedit-export.t ... 1/8 node_values: Bad address at /home/bengen/hivex.git/perl/blib/lib/Win/Hivex/Regedit.pm line 518.
| # Looks like you planned 8 tests but ran 6.
| # Looks like your test exited with 14 just after 6.
| t/550-regedit-export.t ... Dubious, test returned 14 (wstat 3584, 0xe00)
| Failed 2/8 subtests
| t/560-regedit-import.t ... 1/16 node_values: Bad address at /home/bengen/hivex.git/perl/blib/lib/Win/Hivex/Regedit.pm line 518.
| # Looks like you planned 16 tests but ran 2.
| # Looks like your test exited with 14 just after 2.
| t/560-regedit-import.t ... Dubious, test returned 14 (wstat 3584, 0xe00)
| Failed 14/16 subtests
| t/570-regedit-import2.t .. ok
|
| Test Summary Report
| -------------------
| t/210-setvalue.t (Wstat: 3584 Tests: 5 Failed: 0)
| Non-zero exit status: 14
| Parse errors: Bad plan. You planned 11 tests but ran 5.
| t/550-regedit-export.t (Wstat: 3584 Tests: 6 Failed: 0)
| Non-zero exit status: 14
| Parse errors: Bad plan. You planned 8 tests but ran 6.
| t/560-regedit-import.t (Wstat: 3584 Tests: 2 Failed: 0)
| Non-zero exit status: 14
| Parse errors: Bad plan. You planned 16 tests but ran 2.
| Files=11, Tests=30, 1 wallclock secs ( 0.18 usr 0.04 sys + 1.44 cusr 0.16 csys = 1.82 CPU)
| Result: FAIL
| Failed 3/11 test programs. 0/30 subtests failed.
| make[2]: *** [test_dynamic] Error 255
| make[2]: Leaving directory `/home/bengen/hivex.git/perl'
| FAIL: run-perl-tests
| ==================
| 1 of 1 test failed
| ==================
| make[1]: *** [check-TESTS] Error 1
| make[1]: Leaving directory `/home/bengen/hivex.git/perl'
| make: *** [check-am] Error 2
`----
,----
| (sid)bengen@smetana:~/hivex.git/python$ make check
| make check-TESTS
| make[1]: Entering directory `/home/bengen/hivex.git/python'
| 010-import.py
| 020-open.py
| 021-close.py
| 200-write.py
| 210-setvalue.py
| Traceback (most recent call last):
| File "t/210-setvalue.py", line 44, in <module>
| h.node_set_value (b, value1)
| File "/home/bengen/hivex.git/python/hivex.py", line 130, in node_set_value
| return libhivexmod.node_set_value (self._o, node, val)
| RuntimeError: Bad address
| FAIL: run-python-tests
| ==================
| 1 of 1 test failed
| ==================
| make[1]: *** [check-TESTS] Error 1
| make[1]: Leaving directory `/home/bengen/hivex.git/python'
| make: *** [check-am] Error 2
`----
,----
| (sid)bengen@smetana:~/hivex.git/ocaml$ make check
| make check-TESTS
| make[1]: Entering directory `/home/bengen/hivex.git/ocaml'
| PASS: t/hivex_005_load
| PASS: t/hivex_010_open
| PASS: t/hivex_020_root
| 01 non-existent file
| 02 closed handle
| 03 write to read-only file
| 04 node_get_child node not found
| PASS: t/hivex_100_errors
| PASS: t/hivex_110_gc_handle
| PASS: t/hivex_200_write
| Fatal error: exception Hivex.Error("node_values", 9, "Bad address")
| FAIL: t/hivex_300_fold
| ===================
| 1 of 7 tests failed
| ===================
| make[1]: *** [check-TESTS] Error 1
| make[1]: Leaving directory `/home/bengen/hivex.git/ocaml'
| make: *** [check-am] Error 2
`----
13 years, 7 months
[PATCH] [hivex] Use Python's distutils to determine include and site-packages directories.
by Hilko Bengen
The code has been taken from specifically ac_python_devel.m4 published
at <http://ac-archive.sf.net/>, it has turned out to be less
error-prone on my Debian system.
---
configure.ac | 46 ++++++++++++----------------------------------
1 files changed, 12 insertions(+), 34 deletions(-)
diff --git a/configure.ac b/configure.ac
index b82a841..5805ddd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -232,47 +232,25 @@ AC_CHECK_PROG([PYTHON],[python],[python],[no])
PYTHON_PREFIX=
PYTHON_VERSION=
-PYTHON_INCLUDEDIR=
-PYTHON_SITE_PACKAGES=
if test "x$PYTHON" != "xno"; then
PYTHON_PREFIX=`$PYTHON -c "import sys; print sys.prefix"`
PYTHON_VERSION=`$PYTHON -c "import sys; print sys.version[[0:3]]"`
- for d in \
- $PYTHON_PREFIX/include/python$PYTHON_VERSION \
- /usr/include/python$PYTHON_VERSION \
- /usr/local/include/python$PYTHON_VERSION
- do
- AC_MSG_CHECKING([Python.h in $d])
- if test -r "$d/Python.h"; then
- AC_MSG_RESULT([found])
- PYTHON_INCLUDEDIR=$d
- break
- fi
- AC_MSG_RESULT([not found])
- done
- if test "x$PYTHON_INCLUDEDIR" = "x"; then
- AC_MSG_WARN([Python include directory not found])
+
+ AC_MSG_CHECKING([for Python include path])
+ if test -z "$PYTHON_INCLUDEDIR"; then
+ python_path=`$PYTHON -c "import distutils.sysconfig; \
+ print (distutils.sysconfig.get_python_inc ());"`
+ PYTHON_INCLUDEDIR=$python_path
fi
+ AC_MSG_RESULT([$PYTHON_INCLUDEDIR])
- for d in \
- $PYTHON_PREFIX/lib64/python$PYTHON_VERSION/site-packages \
- $PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages \
- /usr/lib64/python$PYTHON_VERSION/site-packages \
- /usr/lib/python$PYTHON_VERSION/site-packages \
- /usr/local/lib/python$PYTHON_VERSION/site-packages
- do
- AC_MSG_CHECKING([for $d])
- if test -d "$d"; then
- AC_MSG_RESULT([found])
- PYTHON_SITE_PACKAGES=$d
- break
- fi
- AC_MSG_RESULT([not found])
- done
- if test "x$PYTHON_SITE_PACKAGES" = "x"; then
- AC_MSG_WARN([Python site-packages directory not found])
+ AC_MSG_CHECKING([for Python site-packages path])
+ if test -z "$PYTHON_SITE_PACKAGES"; then
+ PYTHON_SITE_PACKAGES=`$PYTHON -c "import distutils.sysconfig; \
+ print (distutils.sysconfig.get_python_lib(0,0));"`
fi
+ AC_MSG_RESULT([$PYTHON_SITE_PACKAGES])
old_LIBS="$LIBS"
LIBS="$LIBS -lpython$PYTHON_VERSION"
--
1.7.4.4
13 years, 7 months
Re: [Libguestfs] running libguestfs as a service?
by Richard W.M. Jones
On Sat, Apr 30, 2011 at 01:10:57AM -0400, T Johnson wrote:
> Thanks for responding. I'm by no means a python expert so I could very
> well be doing something wrong, but I've been playing a bit with what
> you've suggested and noted a few interesting things.
>
> 1) As soon as I create 'g', something seems to take over stderr and
> stdout so I can no longer print debugging output like you suggested.
This is very odd. AFAIK nothing in libguestfs should affect stdout or
stderr.
When you say "create 'g'" do you mean "g = guestfs.GuestFS()" (ie.
create the handle) or "g.launch ()" (ie. launch the subprocess)? I
guess it is possible that something in g.launch (ie. forking off a
subprocess) might affect stdout/stderr, although we use it in an awful
lot of other programs and no one has noticed anything before.
Here's my test program:
----------------------------------------------------------------------
#!/usr/bin/python
import sys
import guestfs
print >> sys.stderr, "creating the handle"
g = guestfs.GuestFS()
print >> sys.stderr, "add_drive_ro"
g.add_drive_ro ("/dev/null")
print >> sys.stderr, "launch"
g.launch ()
print >> sys.stderr, "set_verbose"
g.set_verbose (1)
print >> sys.stderr, "delete the handle"
#g.close ()
del g
print >> sys.stderr, "finished"
----------------------------------------------------------------------
BTW you can't directly call g.close() from Python because that method
is not exposed (instead, it is called implicitly when you delete g).
So your program ought to be throwing an exception when you try to call
g.close(). I'm not sure why you are not seeing that.
You're not trying to create the underlying libguestfsmod objects
directly? Don't do that.
Here is the output from my test program:
----------------------------------------------------------------------
creating the handle
add_drive_ro
launch
set_verbose
delete the handle
libguestfs: closing guestfs handle 0x25106a0 (state 2)
libguestfs: send_to_daemon: 44 bytes: 00 00 00 28 | 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 00 | ...
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 01 | 00 12 34 00 | ...
libguestfs: sending SIGTERM to process 13874
finished
----------------------------------------------------------------------
As you can see it's completely as expected
(python-libguestfs-1.11.3-1.fc16.x86_64).
> 2) (I assume) because of #1, g.set_verbose(1) results in no output to
> stdout/stderr either, so it hasn't been helpful so far.
>
> 3) However, I then decided to try g.set_trace(1) and that does provide
> output. In the example I provided before I get this (editing config
> settings in /etc/sysconfig/network):
Unfortunately (because of a bug) closing the handle does not result
in any trace output, except ...
> libguestfs: trace: add_drive "/mnt/images/test_server.img"
> libguestfs: trace: add_drive = 0
> libguestfs: trace: launch
> libguestfs: trace: launch = 0
> libguestfs: trace: mount "/dev/vda1" "/"
> libguestfs: trace: mount = 0
> libguestfs: trace: write "/etc/sysconfig/network" "..."
> libguestfs: trace: write = 0
>
> I can't seem to get any other ouput.. but it is very interesting that
> once I kill the process I see the remainder of the calls failing from
> trace output:
>
> libguestfs: trace: umount_all
> libguestfs: trace: umount_all = -1 (error)
> libguestfs: trace: sync
> libguestfs: trace: sync = -1 (error)
> libguestfs: trace: umount_all
> libguestfs: trace: umount_all = -1 (error)
> libguestfs: trace: sync
> libguestfs: trace: sync = -1 (error)
... when you close a handle which has autosync enabled, which is now
the default, you'll see output like this. It seems like all your
handles are getting closed at once. I have no idea why.
> So, I guess that is what's failing.. but I haven't been able to
> determine why yet.
>
> This is something I've been running into on much older versions of
> libguestfs all the way up to now which I'm trying your recent
> "1.7.17-17.el6" RPMs for rhel6.
Ah, so this could be RHEL 6.0? This could well be a RHEL 6.0 bug.
Definitely try out the RHEL 6.1 packages from:
http://people.redhat.com/~rjones/rhel6.1-libguestfs-preview/
You'll find a lot of things are better. It's much faster for one.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
13 years, 7 months
