similar to: hivex: Exported foreign symbols in libhivex.so.0.0.0

On Wed, Oct 29, 2014 at 10:43:59AM -0500, Mahmoud Al-Qudsi wrote: > Hello all, > > I know that one of the original design goals of libhivex was to be > resilient to corrupt, invalid, or malicious registry hives. I've > encountered some undefined behavior in libhivex when attempting to open > registry files that are too small. I'm not sure if this is a known issue >

> On Nov 11, 2014, at 1:57 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > > Yes I was also meaning to do that after reading lcamtuf's postings. Yup. That's the one. > I just started a run now .. Will let it run for a few days and report > any issues on the list. Thank you. Do you mind running it under valgrind to catch out-of-bound reads? Mahmoud

Hi, On Monday 10 November 2014 18:28:52 Mahmoud Al-Qudsi wrote: > I’m not able to pin it myself from a brief look, but it seems that > under certain conditions a call to hivex_node_delete_child can cause > the allocations from _hivex_get_children to not be freed properly? > > I know that if the return value of _hivex_get_children is -1, no free > is called; but from what I can

> On Nov 11, 2014, at 5:36 AM, Mahmoud Al-Qudsi <mqudsi@neosmart.net> wrote: > I'll test it and be back. And it works perfectly. Thanks, Mahmoud

hivexml on OS X was failing with a symbol-not-found error while dynamically linking. Adding iconv to libhivex fixes the issue and lets OS X process 'images/large' with hivexml. It took careful iconv autotool additions to get compilation working in Fedora as well, but these two lines build and run on OS X 10.6 and 10.8, and Fedora 17 and 18. Unfortunately, a separate issue is revealed

[This email is either empty or too large to be displayed at this time]

Hello, First and foremost - awesome library, beautiful code. Thank you! If I may be so bold as to make my first post to the mailing list a request for an API change, I have attached a patch for a new function in the hivex library that implements obtaining a handle to a "deep" node, allowing the user to enter a path like "SOFTWARE\Intel\Infinst\Uninstall" with only a previous

Hello all, I know that one of the original design goals of libhivex was to be resilient to corrupt, invalid, or malicious registry hives. I've encountered some undefined behavior in libhivex when attempting to open registry files that are too small. I'm not sure if this is a known issue per-se or not, so I figured I'd ask here on the mailing list before I jumped in and started adding

On Wed, Oct 29, 2014 at 09:26:30PM -0500, Mahmoud Al-Qudsi wrote: > On Oct 29, 2014, at 3:39 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > > > >> Or is it expected that certain sanity checks would be performed prior to > >> passing along any files to libhivex? What would those checks be? > > > > No, hivex should definitely have those checks.

On Oct 29, 2014, at 3:39 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > >> Or is it expected that certain sanity checks would be performed prior to >> passing along any files to libhivex? What would those checks be? > > No, hivex should definitely have those checks. > > I'll have a proper look at this in the morning. > > Thanks, > > Rich.

On Thu, Jun 16, 2011 at 01:02:21PM +0300, C?neyt Sina Koca wrote: > Since the code im trying to gave this error : > > ImportError: /usr/lib/pymodules/python2.6/libguestfsmod.so: undefined > symbol: PyCapsule_New > > I copied this libguestfsmod.so.0.0.0 > from python-libguestfs-1.9.10-1.1.x86_64.rpm package and the code works fine > now. > > When I compared the

Hi All, I've created the first tagged version of my LLVM F# bindings (0.0.0) at https://github.com/keithshep/llvm-fs. I basically created this so that I can write an F# based CIL compiler but I hope it's useful to others. Comments and bug reports are welcome. BTW it was very useful to me that the C API was structured in a nice, consistent way. It allowed me to autogen most of the

Hi WEBric won''t strat and showing the following errors:- => Booting WEBrick... /mnt/slash/home/akumar/jruby-1.1b1/lib/ruby/gems/1.8/gems/rails-2.0.2/ lib/initializer.rb:159:in `require_frameworks'': Could not find RubyGem jruby-openssl (>= 0.0.0) (RuntimeError) from /mnt/slash/home/akumar/jruby-1.1b1/lib/ruby/gems/1.8/gems/ rails-2.0.2/lib/initializer.rb:156:in

rawlog files are plain text, readable files. you do not need to dump them with doveadm. can you get gdb "bt full" for the core file? Aki On 10.11.2017 11:35, T. Robers wrote: > Hello everybody, > > i tried to debug imap sessions with the rawlog feature and rawlog > creates files but when i try to dump them doveadm tells me > [...] Error: zlib.read((file)): unexpected EOF

I upgraded an operating system to openSUSE 42.2, kernel 4.4 and recompiled nut 2.7.4. ./configure, make clean and make went well, but make install failed. Make reports Making install in clients make[1]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' make[2]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' /usr/bin/mkdir -p '/usr/lib64'

Hello everybody, i tried to debug imap sessions with the rawlog feature and rawlog creates files but when i try to dump them doveadm tells me [...] Error: zlib.read((file)): unexpected EOF at [...]. I looked at syslog files and i see, that rawlog gets terminated with a segfault, e.g.: segfault at 10 ip 00007ff6da362596 sp 00007fffe725a080 error 4 in libdovecot.so.0.0.0[7ff6da2a4000+122000] Is

https://bugzilla.samba.org/show_bug.cgi?id=13317 Bug ID: 13317 Summary: rsync returns success when target filesystem is full Product: rsync Version: 3.1.2 Hardware: x64 OS: FreeBSD Status: NEW Severity: major Priority: P5 Component: core Assignee: wayned at samba.org

In the kernel and qemu communities it is routine for patches that will be backported to stable branches to be posted for review. I'm proposing we do the same for libguestfs stable branches. All of the attached have been tested with 'make check-release'. Rich.