Re: Proposed F19 Feature: MEMSTOMP
From the feature page: If the executable does not make undefined calls, then it will run normally. If it does make undefined calls you will either get an abort as soon as the undefined call is detected or you will get a backtrace when the undefined call is detected. Does this mean abrt will trigger and a bug could be filed? On the one hand it would be nice to know about problems found by this, but a bunch of abrt reports might not be nice. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
On 01/24/2013 08:00 PM, Chris Adams wrote: Once upon a time, Bill Nottingham nott...@redhat.com said: Jaroslav Reznik (jrez...@redhat.com) said: The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? I would guess that the backtrace code which is not thread safe would mean you couldn't safely do it system-wide. GCC trunk contains a backtrace implementation which is supposedly thread-safe. But it does not work yet with separate debuginfo yet, I think. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: MEMSTOMP
= Features/MEMSTOMP = https://fedoraproject.org/wiki/Features/MEMSTOMP Feature owner(s): Jeff Law l...@redhat.com Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly detect certain library calls which result in undefined behaviour due to overlapping memory arguments. == Detailed description == MEMSTOMP is a DSO which can be preloaded by an application to detect calls to library routines with overlapping memory arguments. Specifically MEMSTOMP will detect calls to the following routines with overalapping memory arguments: [w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy, stp[n]cpy While valgrind can detect these cases, using a DSO such as MEMSTOMP can be significantly faster. The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
Jaroslav Reznik (jrez...@redhat.com) said: = Features/MEMSTOMP = https://fedoraproject.org/wiki/Features/MEMSTOMP Feature owner(s): Jeff Law l...@redhat.com Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly detect certain library calls which result in undefined behaviour due to overlapping memory arguments. == Detailed description == MEMSTOMP is a DSO which can be preloaded by an application to detect calls to library routines with overlapping memory arguments. Specifically MEMSTOMP will detect calls to the following routines with overalapping memory arguments: [w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy, stp[n]cpy While valgrind can detect these cases, using a DSO such as MEMSTOMP can be significantly faster. The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
Once upon a time, Bill Nottingham nott...@redhat.com said: Jaroslav Reznik (jrez...@redhat.com) said: The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? I would guess that the backtrace code which is not thread safe would mean you couldn't safely do it system-wide. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
On Thu, Jan 24, 2013 at 01:29:36PM -0500, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Features/MEMSTOMP = https://fedoraproject.org/wiki/Features/MEMSTOMP Feature owner(s): Jeff Law l...@redhat.com Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly detect certain library calls which result in undefined behaviour due to overlapping memory arguments. == Detailed description == MEMSTOMP is a DSO which can be preloaded by an application to detect calls to library routines with overlapping memory arguments. Specifically MEMSTOMP will detect calls to the following routines with overalapping memory arguments: [w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy, stp[n]cpy While valgrind can detect these cases, using a DSO such as MEMSTOMP can be significantly faster. The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? If all multiarch versions are installed, yeah, you could put /usr/$LIB/memstomp.so into /etc/ld.so.preload Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
Chris Adams (cmad...@hiwaay.net) said: Once upon a time, Bill Nottingham nott...@redhat.com said: Jaroslav Reznik (jrez...@redhat.com) said: The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? I would guess that the backtrace code which is not thread safe would mean you couldn't safely do it system-wide. Well, it's already killing the process at that point - I assumed he meant that the backtrace would be unreliable in the presence of threads. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: MEMSTOMP
= Features/MEMSTOMP = https://fedoraproject.org/wiki/Features/MEMSTOMP Feature owner(s): Jeff Law l...@redhat.com Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly detect certain library calls which result in undefined behaviour due to overlapping memory arguments. == Detailed description == MEMSTOMP is a DSO which can be preloaded by an application to detect calls to library routines with overlapping memory arguments. Specifically MEMSTOMP will detect calls to the following routines with overalapping memory arguments: [w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy, stp[n]cpy While valgrind can detect these cases, using a DSO such as MEMSTOMP can be significantly faster. The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
