From: Simon Marchi <simon.marchi@polymtl.ca>
To: Alex Lindsay <alexlindsay239@gmail.com>
Cc: Philippe Waroquiers <philippe.waroquiers@skynet.be>,
Yao Qi <qiyaoltc@gmail.com>,
gdb@sourceware.org
Subject: Re: Large memory usage by gdb
Date: Mon, 07 Aug 2017 21:34:00 -0000 [thread overview]
Message-ID: <ae7e92e5a287be1738d1dd0cdceff48d@polymtl.ca> (raw)
In-Reply-To: <6b67f471-90f4-7b37-c9f6-18dfd8e5cdfd@gmail.com>
On 2017-08-07 23:04, Alex Lindsay wrote:
> Yes, I've also seen all those errors. I wrote them off to errors in
> the python library but maybe I should have looked more closely
>
> On 08/07/2017 02:53 PM, Philippe Waroquiers wrote:
>> On Mon, 2017-08-07 at 10:14 +0100, Yao Qi wrote:
>>
>>> leaks are bugs, and we should fix them. I can find these leaks in
>>> valgrind too,
>> When running valgrind + gdb on a small program, I also get
>> many errors like the below (GDB 8.0, Debian 8).
>>
>> Do you also see that ?
>>
>>
>> Philippe
>>
>> ==9360== Invalid read of size 4
>> ==9360== at 0x58AD9F3: PyObject_Free (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x4C5E7F: gdb_Py_DECREF (python-internal.h:194)
>> ==9360== by 0x4C5E7F: decref (py-ref.h:36)
>> ==9360== by 0x4C5E7F: ~ref_ptr (gdb_ref_ptr.h:91)
>> ==9360== by 0x4C5E7F: unicode_to_encoded_string(_object*, char
>> const*) (py-utils.c:74)
>> ==9360== by 0x4C5F9C: python_string_to_host_string(_object*)
>> (py-utils.c:158)
>> ==9360== by 0x4BBDDD: get_doc_string(_object*, _object*)
>> (py-param.c:314)
>> ==9360== by 0x4BC11D: parmpy_init(_object*, _object*, _object*)
>> (py-param.c:707)
>> ==9360== by 0x580AD5B: ??? (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5899BE2: PyObject_Call (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x58CD441: PyEval_EvalFrameEx (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x594218F: PyEval_EvalCodeEx (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x589132B: ??? (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5899BE2: PyObject_Call (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x58DC0E4: ??? (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== Address 0x6f0c020 is 1,280 bytes inside a block of size
>> 3,133 free'd
>> ==9360== at 0x4C29B8A: realloc (vg_replace_malloc.c:785)
>> ==9360== by 0x5862625: _PyString_Resize (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x57E40AC: PyUnicodeUCS4_EncodeUTF8 (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5848A98: ??? (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5899BE2: PyObject_Call (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x59416E6: PyEval_CallObjectWithKeywords (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5906C4D: PyCodec_Encode (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x57E4AB4: PyUnicodeUCS4_AsEncodedString (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x4C5E44: unicode_to_encoded_string(_object*, char
>> const*) (py-utils.c:74)
>> ==9360== by 0x4C5F9C: python_string_to_host_string(_object*)
>> (py-utils.c:158)
>> ==9360== by 0x4BBDDD: get_doc_string(_object*, _object*)
>> (py-param.c:314)
>> ==9360== by 0x4BC11D: parmpy_init(_object*, _object*, _object*)
>> (py-param.c:707)
>> ==9360== Block was alloc'd at
>> ==9360== at 0x4C27BF5: malloc (vg_replace_malloc.c:299)
>> ==9360== by 0x5864249: PyString_FromStringAndSize (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x57E41C6: PyUnicodeUCS4_EncodeUTF8 (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5848A98: ??? (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5899BE2: PyObject_Call (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x59416E6: PyEval_CallObjectWithKeywords (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x5906C4D: PyCodec_Encode (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x57E4AB4: PyUnicodeUCS4_AsEncodedString (in
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
>> ==9360== by 0x4C5E44: unicode_to_encoded_string(_object*, char
>> const*) (py-utils.c:74)
>> ==9360== by 0x4C5F9C: python_string_to_host_string(_object*)
>> (py-utils.c:158)
>> ==9360== by 0x4BBDDD: get_doc_string(_object*, _object*)
>> (py-param.c:314)
>> ==9360== by 0x4BC11D: parmpy_init(_object*, _object*, _object*)
>> (py-param.c:707)
>>
>>
This is expected with Python:
https://svn.python.org/projects/python/trunk/Misc/README.valgrind
Simon
next prev parent reply other threads:[~2017-08-07 21:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 20:20 Alex Lindsay
2017-07-25 20:28 ` Philippe Waroquiers
2017-07-31 22:11 ` Alex Lindsay
2017-08-01 19:12 ` Philippe Waroquiers
[not found] ` <420b109c-1610-d687-ae9a-b172542fafca@gmail.com>
2017-08-04 21:43 ` Alex Lindsay
2017-08-07 9:16 ` Yao Qi
2017-08-07 19:53 ` Philippe Waroquiers
2017-08-07 21:04 ` Alex Lindsay
2017-08-07 21:34 ` Simon Marchi [this message]
2017-08-07 18:19 ` Philippe Waroquiers
2017-07-26 7:28 ` Yao Qi
[not found] ` <4fc14853-b066-4fd7-f0c9-b98f442a9a95@gmail.com>
2017-07-26 15:55 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ae7e92e5a287be1738d1dd0cdceff48d@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=alexlindsay239@gmail.com \
--cc=gdb@sourceware.org \
--cc=philippe.waroquiers@skynet.be \
--cc=qiyaoltc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox