==18779== 800,000 bytes in 196 blocks are definitely lost in loss record 29 of 29
==18779== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18779== by 0x4E635C3: receive (analog.c:319)
==18779== by 0x40870B: datafeed_in (session.c:316)
==18779== by 0x4E59D4E: sr_session_send (session.c:1201)
==18779== by 0x4E59F8B: sr_session_send (session.c:1159)
==18779== by 0x4E62595: send_chunk (wav.c:234)
==18779== by 0x4E62A06: process_buffer (wav.c:290)
==18779== by 0x40954A: load_input_file_module (input.c:123)
==18779== by 0x4097AB: load_input_file (input.c:157)
==18779== by 0x40531E: main (main.c:288)
==17549== 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 22 of 39
==17549== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17549== by 0x5359200: g_malloc (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x536EE2D: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x5370165: g_slist_append (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x4E595C3: sr_session_datafeed_callback_add (session.c:512)
==17549== by 0x409527: load_input_file_module (input.c:111)
==17549== by 0x4097AB: load_input_file (input.c:157)
==17549== by 0x40531E: main (main.c:288)
==7478== Invalid write of size 8
==7478== at 0x4E59182: sr_session_dev_remove_all (session.c:302)
==7478== by 0x4E591CD: sr_session_destroy (session.c:265)
==7478== by 0x4095D9: load_input_file_module (input.c:143)
==7478== by 0x4097AB: load_input_file (input.c:157)
==7478== by 0x40531E: main (main.c:288)
==7478== Address 0x7877eb8 is 88 bytes inside a block of size 96 free'd
==7478== at 0x4C2A37C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7478== by 0x4E5F454: sr_input_free (input.c:573)
==7478== by 0x4095C3: load_input_file_module (input.c:140)
==7478== by 0x4097AB: load_input_file (input.c:157)
==7478== by 0x40531E: main (main.c:288)
Do not use size_t for values whose width is defined by the device,
not the host. Also don't use size_t for simple indices with known
small range, unless type compatibility considerations apply.
Refactor the sysclk-lwla driver to separate the generic logic from
the model-specific implementation. Based on this, implement support
for the SysClk LWLA1016 device.
On some systems it can happen that the USB 'bus' number is a lot larger
than 64, but sr_usb_find() currently errors out if it is > 64.
Example:
Bus 250 Device 006: ID 1ab1:04ce 1ab1 DS1000Z Series[...]
Increase that limit so that the code will work everywhere. This bus number
is queried via libusb_get_bus_number() which returns an uint8_t, so we're
limiting to 255 here.
Thanks to 'ssi' on IRC for reporting the issue.
Apparently (some versions of) Mac OS X have the same problem with
usb_get_port_path() as FreeBSD does. Work around this in the same way.
Thanks to hanyazou@gmail.com for the patch!
This fixes bug #673.
The driver should now be able to cope with e.g. multiple ChronoVu LA8
and/or ChronoVu LA16 devices being connected to the same PC.
It now also provides the serial number and connection ID, which can be
used by frontends to differentiate multiple devices.
Also improve the scanopts / drvopts / devopts lists handling.
This fixes bug #504.
Set both CFLAGS and CXXFLAGS when executing setup.py to build
the Python bindings. Newer versions of distutils/setuptools have
apparently started to pick up the latter when compiling C++.
Check for either Python 2 or Python 3 header files depending on
the version of the Python interpreter. Also require the module
version to exactly match the interpreter version.
This may fix bug #645.
With the current driver API and the corresponding session event
handling, it is not possible to destroy and then re-create an
event source with the same key within the same main loop iteration.
The next generation driver API will fix this problem. But for now,
just change the driver to make do without that sort of thing. Also
increase the I/O timeout to 100 ms to be safer in the event of all
kind of delays the OS environment may induce.
This fixes bug #678.
Evaluate all 64 bit of the duration field in the capture status
record. Although unlikely in practical use, due to compression
it is possible for the duration in ms to exceed 32 bit.