search for: libsigsegv

On Tuesday 10 March 2009 21:47:59 someguy wrote: > From a cursory glance, it looks like something is messing with the > stack canarys. Probably a stack buffer overflow. In case it is relevant, HLVM uses libsigsegv to detect stack overflows and that stack handler is initialized in my JITted code which LLVM's runFunction should be calling. Could libsigsegv be conflicing with the stack smashing code? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Mar 10, 2009, at 3:07 PM, Jon Harrop wrote: > On Tuesday 10 March 2009 21:47:59 someguy wrote: >> From a cursory glance, it looks like something is messing with the >> stack canarys. Probably a stack buffer overflow. > > In case it is relevant, HLVM uses libsigsegv to detect stack > overflows and > that stack handler is initialized in my JITted code which LLVM's > runFunction > should be calling. > > Could libsigsegv be conflicing with the stack smashing code? If it changes known values on the stack - yes. Basically it all works by...

...05 2122025 /lib/libgcc_s.so.1 b7f33000-b7f34000 rw-p 0000d000 08:05 2122025 /lib/libgcc_s.so.1 b7f34000-b7f61000 r-xp 00000000 08:05 2121805 /lib/libncurses.so.5.6 b7f61000-b7f64000 rw-p 0002c000 08:05 2121805 /lib/libncurses.so.5.6 b7f64000-b7f66000 r-xp 00000000 08:05 4358492 /usr/lib/libsigsegv.so.0.0.0 b7f66000-b7f68000 rw-p 00001000 08:05 4358492 /usr/lib/libsigsegv.so.0.0.0 b7f68000-b804b000 r-xp 00000000 08:05 5177913 /usr/lib/libstdc++.so.6.0.10 b804b000-b804f000 r--p 000e3000 08:05 5177913 /usr/lib/libstdc++.so.6.0.10 b804f000-b8050000 rw-p 000e7000 08:05 5177913 /usr/lib/libstdc++....

..._s.so.1 > b7f33000-b7f34000 rw-p 0000d000 08:05 2122025    /lib/libgcc_s.so.1 > b7f34000-b7f61000 r-xp 00000000 08:05 2121805    /lib/libncurses.so.5.6 > b7f61000-b7f64000 rw-p 0002c000 08:05 2121805    /lib/libncurses.so.5.6 > b7f64000-b7f66000 r-xp 00000000 08:05 4358492 > /usr/lib/libsigsegv.so.0.0.0 > b7f66000-b7f68000 rw-p 00001000 08:05 4358492 > /usr/lib/libsigsegv.so.0.0.0 > b7f68000-b804b000 r-xp 00000000 08:05 5177913 > /usr/lib/libstdc++.so.6.0.10 > b804b000-b804f000 r--p 000e3000 08:05 5177913 > /usr/lib/libstdc++.so.6.0.10 > b804f000-b8050000 rw-p 000e700...

...itive types. . Tuples (as first-class structs). . Homogeneous array type. . Boxed value type. . Function pointers. . Generic printing. . Full tail calls. . Precise garbage collection. . Foreign function interface to C. . JIT compilation to native code using LLVM. . Catching of stack overflows using libsigsegv. The GC is brand new (I wrote it over the weekend) and I need to fix and optimize it before moving HLVM into beta but the code already includes a variety of example programs (written in ASTs) including Sieve of Eratosthenes, Mandelbrot Rendering and n-Queens Solvers. Apart from the GC, perform...

Hi, as discussed in [1], this series adds a new getprogname module. All it does is providing a getprogname function, much like what is found on e.g. *BSD systems, and using it in gnulib instead of progname. Also, using it explicitly by modules avoids gnulib users the need of either use the progname module (GPL), or to provide program_name (and call set_program_name manually, which is not always

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..0943bf305 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 --- v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..93d1a9ecd 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on

Hopefully this time ...