similar to: valgrind and libusb calls

Sorry about the noise guys. Below a significantly improved patch. The main difference is that all calls to usb_get_string_.. have been wrapped in a new function nut_usb_get_string()  that is implemented in libusb.c This was necessary in order to make the bufflen_fix available in libusb.c where usb_get_string() is called in libusb_open() This wrapper function mops up and hides all the work

Dear all, I'm trying to debug my R package with valgrind, but I cannot get past the point where I load make the data, as valgrind crashes when trying to extract a single time series object of a multivariate mts object. I'm using R 2.15.0 with platform x86_64-redhat-linux-gnu (64-bit). The valgrind.R contains code data(Seatbelts) y<-Seatbelts[,"VanKilled"] And I run

I'm running FreeBSD 6.2 with Nut 2.0.5 installed from ports... I have a TrippLite OmniVS1500XL plugged in, but I'm having little luck with the tripplite_usb module. I have already built and booted a new kernel with UHID disabled so that libusb can grab /dev/ugen0. At first I was able to get the following out of the driver: # USB_DEBUG=5 /usr/local/libexec/nut/tripplite_usb -u root

Howdy, I had this working with lots of help for a developer before (Charles Lepple), but after upgrading to a somewhat more current version of FreeBSD the patched-up version stopped working. Seeing as this was more than a few years ago, I thought I'd give a new libusb and NUT a try to see if it might work out of the box. So far, no luck. Some info: FreeBSD 6.3 libusb 0.1.12 NUT 2.4.1

Full_Name: Martin Schlather Version: 2.10.0 OS: linux Submission from: (NULL) (91.3.220.231) Bug summary: some functions behave differently for NAs when valgrind is used in R, e.g. sum and prod Bug demonstration: --- without valgrind ---- > sum(c(NA,1)[1]) [1] NA --- with valgrind ---- > sum(c(NA,1)[1]) [1] NaN R call with valgrind: R -d "valgrind --tool=memcheck

By default valgrind suppresses many leaks. I'm not even sure exactly how it decides which ones to suppress, but certainly global variables pointing to malloc’d data are suppressed, which is not useful behaviour. Tell valgrind to show all leaks. It won't give an error on them. However to do this we also need a much more comprehensive list of suppressions so that we don't constantly

Hi: I have been working on Valgrind [porting it to non-supported architectures] and wanted to know what you guys think of Valgrind for LLVM. I haven't thought through fully myself - so wanted to get your inputs before becoming rigid in my own opinion. Original Valgrind works on object code - translating the asm to its own IR [intermediate representation]. But for LLVM, probably putting the

I had to add several suppressions because Python leaks memory by design, and also increase the max depth of valgrind stack traces because Python stack traces are very deep. Note that to do proper valgrinding of Python itself we would need to specially recompile Python: https://svn.python.org/projects/python/trunk/Misc/README.valgrind --- tests/test-lang-plugins.c | 3 +-

Hello. I want to compile trunk speex. ./configure --prefix=/opt/speex --enable-option-checking --disable-silent-rules --disable-maintainer-mode \ --enable-shared=yes --enable-static=yes --enable-fast-install=yes --enable-dependency-tracking \ --enable-libtool-lock --enable-valgrind --enable-sse --enable-binaries --enable-vbr \ --disable-fixed-point-debug --enable-vorbis-psy --with-pic

I am trying to do a classic R -d valgrind --vanilla < mypkg-Ex.R as described in http://cs.swan.ac.uk/~csoliver/ok-sat-library/internet_html/doc/doc/R/2.9.1/doc/manual/R-exts.html#Using-valgrind The problem is valgrind crashes imediately. I am using Ubuntu 10.04 LST (actually Biolinux) on a 64bit Dell Precision laptop with 4 core-i5 Intel processors. I have R-2-15-0 installed from source

Hello, I 'm trying to set up an Eaton PW5110 using nut-2.4.1 in OpenBSD, my ups.conf follows : [myups] driver = bcmxcp_usb port = auto desc = "Eaton PW 5110 (1500VA)" My first attempt to run upsdrvctl ended up complaining about unimplemented usb_clear_halt() in libusb. I patched libusb-0.1.12 with the following patch :

Like Glen Ogilvie, I got a newer Dynamix 650 VA with USB connection, and was having trouble getting NUT to communicate with it. This appears to be the UPS that megatec_usb was built for - Vendor: 0x0001, Product: 0x0000, uses Megatec's software, has USB chip attached to internal serial lines, and has terrible USB implementation with fake HID tables. But megatec_usb would consistently fail.

Hello, I have been trying to get a TrippLite Internet Office 750 UPS to talk to my Linux PBX for a couple of evenings now and I'm getting nowhere... I tried searching the list archives before posting here (I'm sure I'm not the first one to try to get this going) but they seem to be offline... The UPS is unfortunately USB based but I thought I'd give it a try anyway. Here is

Dear R developers I am running an instrumented build of R 2.6.1 on ubuntu, compiled with option configure --with-valgrind-instrumentation=3. If run valgrind R then I get all sorts of warnings. I was wondering whether I should worry about them or not. First, when I open R as follows: $R -d "valgrind --tool=memcheck --leak-check=full --show-reachable=yes" --vanilla I get a whole

As an update to the nouveau development community, the downstream fork of Valgrind with a mmap tracing tool ("mmt") we maintain has been rebased against the latest upstream release of Valgrind, v3.16.1 Code branch: https://github.com/envytools/valgrind/tree/mmt-3.16.1 Features of upstream Valgrind 3.16.x: https://www.valgrind.org/docs/manual/dist.news.html In selected highlights, the

valgrind complains about the save command in R 2.3.1 as shown by the script included below. Of course, I don't know whether this "Conditional jump or move depends on uninitialised value(s)" is really a bug. Experience with similar issues in my own code says it may be, but it is also hard to tell. Having no familiarity with the code cited in deflate.c, I leave the issue to experts.

If you've ever tried to use this option, you'll know that it didn't work well. It broke random things (probably RHBZ#1020216, definitely RHBZ#1023630), and caused random failures generally, while often not actually failing when valgrind itself found problems. This does not remove the guestfs_internal_exit API. That will instead be modified in a future commit. ---

Hi, only one letter got to valgrind-developers mailing list. I'll quote the first message of the thread so that those who do not read llvmdev knew what's this discusssion about. === Begin of the first message === > Hi, > > I've seen on the LLVM's Open Projet Page [1] an idea about using LLVM to > generate native code in Valgrind. For what I know, Valgrind uses libVEX

Hi, I am trying to debug a package which I helped to develop since we were notified by CRAN that our package randomly fails to run its examples. Hence, I reinstalled R with "with-valgrind-instrumentation=2" and installed our package with MAKEFLAGS="CFLAGS='-O0 -g3' CXXFLAGS='-O0 -g3'" R CMD INSTALL --build hsmm Then, I ran the examples of our package with R

I just upgraded the FreeBSD buildbot machine from 6.4 to 8.0, and I ran across some interesting differences. The libusb API that we use (0.1) is available in /usr/include/usb.h and /usr/lib/libusb.* as before, but it seems to be the compatibility layer from libusb 1.0. However, it doesn't include the libusb-config binary. This is from the 'ports' Makefile for NUT: ########## - -