From: Alex Lindsay <alexlindsay239@gmail.com>
To: Philippe Waroquiers <philippe.waroquiers@skynet.be>,
Yao Qi <qiyaoltc@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Large memory usage by gdb
Date: Mon, 07 Aug 2017 21:04:00 -0000 [thread overview]
Message-ID: <6b67f471-90f4-7b37-c9f6-18dfd8e5cdfd@gmail.com> (raw)
In-Reply-To: <1502135603.1467.33.camel@skynet.be>
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)
>
>
next prev parent reply other threads:[~2017-08-07 21:04 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 [this message]
2017-08-07 21:34 ` Simon Marchi
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=6b67f471-90f4-7b37-c9f6-18dfd8e5cdfd@gmail.com \
--to=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