[USRP-users] Memory leak when querying E310 temperature sensor

Marcus Müller marcus.mueller at ettus.com
Wed Mar 2 11:23:23 EST 2016


Definitely helps!
Will dig deeper.

Best regards,
Marcus

On 03/02/2016 04:23 PM, Daniel May wrote:
> Marcus,
>
> Thanks for the reply. I didn't notice anything suspicious in the uhd
> source either, which had me scratching my head and wondering if it was
> something specific to my setup. Hence the need for someone to reproduce.
>
> I have an application that runs continuously on an E310 which is in a
> weather proof enclosure outside. As part of its operation, the
> application queries the temperature sensor periodically to monitor max
> mboard temp throughout the day as I'm worried about overheating (no
> airflow in the enclosure). The application started becoming slow to
> respond, so I checked memory usage by the process, and it was way
> higher than expected. After a good bit of digging, I narrowed the
> cause down to the querying of the temperature sensor.
>
> Not sure how many bytes are being consumed on each call. I haven't
> gone so far as to cross-compile valgrind tools and run with massif. I
> checked it using linux's sysinfo function, which doesn't give you
> per-call resolution and is somewhat unreliable, but I'm seeing
> anywhere from 2-5 kB (!!) consumed per call. 
>
> As a sanity check, I ran this on another E310 using the same image and
> saw the same result.
>
> Hope this additional info helps. Let me know if there's anything
> specific you'd like me to try on my end.
>
> -Daniel
>
> On Wed, Mar 2, 2016 at 1:08 AM, Marcus Müller
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
>
>     Hi Daniel,
>
>     interesting! I'm on the run, so this is going to be hard to
>     reproduce right now, but:
>     Looking at the code, neither ad9361_ctrl::get_temperature [1] nor
>     the underlying ad9361_device::_get_temperature and
>     ::get_average_temperature [2] does anything suspicious -- no
>     allocation of memory, no call into functions that might just
>     increase some internal buffer or so.
>
>     So: this looks like it would be hard to find to me :) thanks! So:
>     how/in what context did you notice? How large is that leak (in
>     Bytes per loop iteration)?
>
>     Best regards,
>     Marcus
>
>     [1]
>     https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/common/ad9361_ctrl.cpp#L199
>     [2]
>     https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp#L2180
>
>
>     On 02.03.2016 04:52, Daniel May via USRP-users wrote:
>>     Hello,
>>
>>     Using E310 image:
>>     http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg1/sdimage-gnuradio-demo.direct.xz
>>
>>     linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>>
>>     The following program:
>>
>>     --------------------------------------------------------------------------------------
>>     int main() {
>>
>>       std::string args = "";
>>
>>       uhd::usrp::multi_usrp::sptr usrp =
>>     uhd::usrp::multi_usrp::make(args);
>>
>>       while(1) {
>>         usrp->get_mboard_sensor("temp").to_real();
>>       }
>>
>>       return 0;
>>     }
>>     --------------------------------------------------------------------------------------
>>
>>     continuously consumes memory with each query to the sendor on the
>>     E310. I'm not seeing this problem with any of the other E310
>>     sensors, only the "temp" sensor.
>>
>>     Can anyone confirm this behavior?
>>
>>     Thanks,
>>     Daniel
>>
>>
>>     _______________________________________________
>>     USRP-users mailing list
>>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160302/88c7eaf1/attachment-0002.html>


More information about the USRP-users mailing list