gcc-python-plugin May 2014

gcc-python-plugin@lists.stg.fedorahosted.org

2 participants
5 discussions

some messages pointing to line zero
by Buck Golemon 27 May '14

27 May '14

For example: http://bukzor.github.io/MySQLdb1/build/temp.linux-x86_64-2.7/_mysql.c._mysq… The first two messages have no annotated line number because they point to line zero. http://bukzor.github.io/MySQLdb1/build/temp.linux-x86_64-2.7/_mysql.c._mysq… Looking at the various reports, this behavior seems pretty random. Sometimes the 'found X similar traces' is attached to the final line, sometimes to zero. Looking at the json for that report, I see a whole bunch of location:null / message:null / message:''. Is something going wrong? In particular, it would be helpful to show the message:"returning", but its location is null.

1 0

exception function
by Buck Golemon 27 May '14

27 May '14

MySQLdb has a non-trivial function which picks the correct exception type and fills in its data when there's a problem. As far as I can see, it always sets and error and returns NULL. In the couple functions which to not return pyobject, that null is not returned, and I get a spurious memory leak flagged in gcc-python-plugin. Is there a way to enable gcc-python-plugin to correctly analyze this? I'm specifically talking about this message: http://bukzor.github.io/MySQLdb1/build/temp.linux-x86_64-2.7/_mysql.c._mysq… Full listing here: http://bukzor.github.io/MySQLdb1/

1 0

confusing result
by Buck Golemon 21 May '14

21 May '14

I don't understand why *s would have anything other than 0 refcount in this example. It seems like the system is disregarding lines 1139 and 1140. http://bukzor.github.io/MySQLdb1/build/temp.linux-x86_64-2.7/_mysql.c._mysq…

2 6

cc1: error: Unhandled Python exception raised calling 'execute' method
by Buck Golemon 19 May '14

19 May '14

I can't tell what's really going wrong because apport is segfaulting while trying to record the issue... (gdb) py-bt #12 Frame 0x1c0eb00, for file /usr/lib/python2.7/dist-packages/apt/__init__.py, line 23, in <module> () import apt_pkg #28 Frame 0x25cdd30, for file /usr/lib/python2.7/dist-packages/apport/packaging_impl.py, line 20, in <module> () import apt #42 Frame 0x2177940, for file /usr/lib/python2.7/dist-packages/apport/fileutils.py, line 23, in <module> () from apport.packaging_impl import impl as packaging #56 Frame 0x1a17c30, for file /usr/lib/python2.7/dist-packages/apport/report.py, line 30, in <module> () import apport.fileutils #70 Frame 0x27c9430, for file /usr/lib/python2.7/dist-packages/apport/__init__.py, line 5, in <module> () from apport.report import Report #86 Frame 0x18e3e80, for file /usr/lib/python2.7/dist-packages/apport_python_hook.py, line 63, in apport_excepthook (exc_type=<type at remote 0x7ffff610e540>, exc_obj=exceptions.ValueError('Could not find filename for location',), exc_tb=<traceback at remote 0x7ffff01d9c90>, StringIO=<built-in function StringIO>, re=<module at remote 0x7ffff526e2d0>, traceback=<module at remote 0x7ffff35d2e30>) from apport.fileutils import likely_packaged, get_recent_crashes I had to comment it out of sitecustomize.py and finally got this stack: Traceback (most recent call last): File "/home/buck/trees/theirs/gcc-python-plugin/libcpychecker/__init__.py", line 79, in execute self._check_refcounts(fun) File "/home/buck/trees/theirs/gcc-python-plugin/libcpychecker/__init__.py", line 85, in _check_refcounts dump_json=self.dump_json) File "/home/buck/trees/theirs/gcc-python-plugin/libcpychecker/refcounts.py", line 4361, in check_refcounts maxtrans) File "/home/buck/trees/theirs/gcc-python-plugin/libcpychecker/refcounts.py", line 4314, in impl_check_refcounts trace, endstate, fun, rep) File "/home/buck/trees/theirs/gcc-python-plugin/libcpychecker/refcounts.py", line 4148, in warn_about_NULL_without_exception w.add_trace(trace, ExceptionStateAnnotator()) File "/home/buck/trees/theirs/gcc-python-plugin/libcpychecker/diagnostics.py", line 240, in add_trace describe_trace(trace, self, annotator) File "/home/buck/trees/theirs/gcc-python-plugin/libcpychecker/diagnostics.py", line 85, in describe_trace 'reaching: %s' % get_src_for_loc(destloc)) File "/home/buck/trees/theirs/gcc-python-plugin/gccutils/__init__.py", line 27, in get_src_for_loc return linecache.getline(loc.file, loc.line).rstrip() ValueError: Could not find filename for location I had to use this patch to get that stack trace rather than a segfault: diff --git a/generate-location-c.py b/generate-location-c.py index 7056617..7d302e0 100644 --- a/generate-location-c.py +++ b/generate-location-c.py @@ -38,7 +38,14 @@ def generate_location(): static PyObject * PyGccLocation_get_file(struct PyGccLocation *self, void *closure) { - return PyGccString_FromString(gcc_location_get_filename(self->loc)); + const char *result = gcc_location_get_filename(self->loc); + if (result == NULL) { + PyErr_SetString(PyExc_ValueError, + "Could not find filename for location"); + return (PyObject *)NULL; + } else { + return PyGccString_FromString(result); + } } """) This is the code I'm trying to check, if you want to reproduce the issue: $ git remote -v origin git@github.com:bukzor/MySQLdb1.git (fetch) origin git@github.com:bukzor/MySQLdb1.git (push) $ git rev-parse HEAD 0c156e3b34478bcda4c038a9fba67bf5bc07fda4 Finally, this is the command I'm running to reproduce the issue: $ cat repro.sh LD_LIBRARY_PATH=/home/buck/trees/theirs/gcc-python-plugin/gcc-c-api/ gdb --args /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -v -I /usr/include/mysql -I /usr/include/python2.7 -imultiarch x86_64-linux-gnu -iplugindir=/usr/lib/gcc/x86_64-linux-gnu/4.8/plugin -D NDEBUG -D version_info='(1, 2, 4, ufinal, 1)' -D __version__=1.2.4 -D BIG_JOINS=1 -D NDEBUG _mysql.c -iplugindir=/usr/lib/gcc/x86_64-linux-gnu/4.8/plugin -quiet -dumpbase _mysql.c -mtune=generic -march=x86-64 -auxbase-strip build/temp.linux-x86_64-2.7/_mysql.o -g -g -O2 -Wall -Wstrict-prototypes -version -fplugin=/home/buck/trees/theirs/gcc-python-plugin/python.so -fplugin-arg-python-command='from libcpychecker import main; main(**{"verify_refcounting":True, "maxtrans":256, "dump_json":0})' -fwrapv -fPIC -fno-strict-aliasing -fstack-protector -Wformat -Wformat-security -o /tmp/ccqnoYh9.s # python exec(open('/usr/lib/debug/usr/bin/python2.7-dbg-gdb.py').read())

2 4

Re: _mysql.c:1522:2: internal compiler error: Segmentation fault
by Buck Golemon 19 May '14

19 May '14

and, finally, attached is the full backtrace with python support installed (trick is python-interactive, exec(open('/usr/lib/debug/usr/bin/ python2.7-dbg-gdb.py').read())) On Sun, May 18, 2014 at 1:49 PM, Buck Golemon <buck(a)yelp.com> wrote: > I've attached the preprocessed source, as I was instructed by the error > message. > > Here's the full error message, as well as the information you'd need to > reproduce it: > http://paste.pound-python.org/show/iDPlF2etujYpbx2xAa5n/ > > > I'm finding it hard to get a gdb wrapped around that segfault even though > I can reproduce it reliably: > I tried: > > 1. gdb --args gcc-with-cpychecker > 2. gdb --args python gcc-with-cpychecker > 3. edited gcc-with-cpychecker to contain args = ['gdb', '--args', > 'gcc', > > To no avail. >

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

gcc-python-plugin May 2014