[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Fixed under bug #415042. Output from valgrind for MQTTAsync_publish now
looks like:
[icraggs@oc8720822567 samples]$ LD_LIBRARY_PATH=../linux_ia64/ valgrind
./MQTTAsync_publish
==18495== Memcheck, a memory error detector
==18495== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==18495== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==18495== Command: ./MQTTAsync_publish
==18495==
Waiting for publication of Hello World!
on topic MQTT Examples for client with ClientID: ExampleClientPub
Successful connection
Message with token value 1 delivery confirmed
Successful disconnection
==18495==
==18495== HEAP SUMMARY:
==18495== in use at exit: 0 bytes in 0 blocks
==18495== total heap usage: 272 allocs, 272 frees, 144,885 bytes allocated
==18495==
==18495== All heap blocks were freed -- no leaks are possible
==18495==
==18495== For counts of detected and suppressed errors, rerun with: -v
==18495== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[icraggs@oc8720822567 samples]$
Ian
On 08/13/2013 03:40 PM, Ian Craggs wrote:
The invalid read is at line 2621 of MQTTAsync.c. It should be:
if (command->command.token == msgid)
instead of
if (command->command.token == ((Puback*)pack)->msgId)
I'd already created the variable msgid to hold the message id before
the packet was freed, but forgot to use it in this case.
The "memory leaks" are the creation of two threads, which by default
are not detached, and then they aren't joined at the end. I will set
them to detached.
Ian
On 08/13/2013 12:59 PM, Roger Light wrote:
Hi Ian,
I took a look earlier and the invalid read looks as though it is an
error. The two memory leaks... I'm not sure whether they repeat or
not. It seems as though we could be leaking memory on a reconnect but
I'm not familiar enough with the code to say, and if I try to produce
a reconnect with MQTTAsync_subscribe.c, the client segfaults when I
kill the broker it is connected to.
A quick fix to MQTTAsync_subscribe.c is:
- MQTTAsync_setCallbacks(client, NULL, connlost, msgarrvd, NULL);
+ MQTTAsync_setCallbacks(client, client, connlost, msgarrvd,
NULL);
But then I end up only being able to reconnect once. It doesn't
segfault, but does refuse to reconnect after the first time.
Cheers,
Roger
On Tue, Aug 13, 2013 at 11:21 AM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Herry,
thanks for the report. I'll look at it.
Ian Craggs
On 08/13/2013 07:52 AM, Herry Sitepu wrote:
Dear all,
I use the master branch and perform test the MQTTAsync_publisher.c
using
valgrind, here is the output:
./vg ./MQTTAsync_publish
==30127== Memcheck, a memory error detector
==30127== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward
et al.
==30127== Using Valgrind-3.7.0 and LibVEX; rerun with -h for
copyright info
==30127== Command: ./MQTTAsync_publish
==30127==
Waiting for publication of Hello World!
on topic MQTT Examples for client with ClientID: ExampleClientPub
Successful connection
==30127== Thread 3:
==30127== Invalid read of size 4
==30127== at 0x4E39C7A: MQTTAsync_cycle (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x4E39E85: MQTTAsync_receiveThread (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x50E8E99: start_thread (pthread_create.c:308)
==30127== Address 0x56e2cc8 is 8 bytes inside a block of size 24
free'd
==30127== at 0x4C2A82E: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30127== by 0x4E34DAC: myfree (in /usr/local/lib/libmqttv3a.so)
==30127== by 0x4E3E072: MQTTProtocol_handlePubacks (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x4E39C29: MQTTAsync_cycle (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x4E39E85: MQTTAsync_receiveThread (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x50E8E99: start_thread (pthread_create.c:308)
==30127==
Message with token value 1 delivery confirmed
Successful disconnection
==30127==
==30127== HEAP SUMMARY:
==30127== in use at exit: 544 bytes in 2 blocks
==30127== total heap usage: 250 allocs, 248 frees, 139,498 bytes
allocated
==30127==
==30127== Thread 1:
==30127== 272 bytes in 1 blocks are possibly lost in loss record 1 of 2
==30127== at 0x4C29DB4: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30127== by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==30127== by 0x50E9ABC: pthread_create@@GLIBC_2.2.5
(allocatestack.c:571)
==30127== by 0x4E410D0: Thread_start (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x4E3856A: MQTTAsync_connect (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x400E3B: main (MQTTAsync_publish.c:129)
==30127==
==30127== 272 bytes in 1 blocks are possibly lost in loss record 2 of 2
==30127== at 0x4C29DB4: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30127== by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==30127== by 0x50E9ABC: pthread_create@@GLIBC_2.2.5
(allocatestack.c:571)
==30127== by 0x4E410D0: Thread_start (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x4E385AF: MQTTAsync_connect (in
/usr/local/lib/libmqttv3a.so)
==30127== by 0x400E3B: main (MQTTAsync_publish.c:129)
==30127==
==30127== LEAK SUMMARY:
==30127== definitely lost: 0 bytes in 0 blocks
==30127== indirectly lost: 0 bytes in 0 blocks
==30127== possibly lost: 544 bytes in 2 blocks
==30127== still reachable: 0 bytes in 0 blocks
==30127== suppressed: 0 bytes in 0 blocks
==30127==
==30127== For counts of detected and suppressed errors, rerun with: -v
==30127== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2
from 2)
I'm really sorry because I can't help to fix this memory issue because
org.eclipse.paho.mqtt.c is quite complex. Could someone look at this
report
from valgrind. Should I ignore this?
Regards,
Herry Sitepu
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
