Hi Simon, On Fri, Aug 7, 2009 at 8:09 AM, Simon King<simon.k...@nuigalway.ie> wrote: > > Hi! > > Currently I am puzzled by a bug, and so far my approaches to tackle it > down failed. I guess I should use debugging tools such as gdb, but I > did not find a tutorial or wiki page concerning "sage -gdb". For > example: When I start "sage -gdb", how do I get the gdb prompt so that > I can set break points? > > I do not expect that you can guess the source of the problem from the > following description; but at least you may understand why I am > puzzled. > > I have an instance of some Cython extension class, relying on C > data.Given certain input data, some method results in a "glibc > detected: invalid next size" in openSUSE 11.0, Intel Core Duo, > respectively in a SIGBUS on sage.math (and after the SIGBUS I don't > get a prompt from the system, so, I have to shut down ssh), > respectively SIGSEGV on sage.math when running sage -gdb.
This is unrelated but: the version of GCC that is distributed with openSUSE 11.0 is $ gcc --version gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If you read carefully, it's a prerelease version of GCC, not a stable release. If find this puzzling because openSUSE 11.0 (which is meant to be a stable release of that distribution) is bundled with a prerelease of GCC. This doesn't mean that one cannot compile Sage using that distribution. I have successfully compiled Sage on that version of openSUSE. But when I ran the Sage test suite, I received a lot of failures. > While debugging, I saved "self", in order to have a more easily > reproducible example. But after loading the saved data, there is no > crash. > > Now comes the strange thing: > I found out that the error also disappears if inside the function I > insert in the right place the line > N = loads(dumps(self)) > So, self should not be changed by this line, but the error vanishes. > dumps alone does not suffice. > > The method in question gets a list "el" as parameter. > I get an iterator from it, and give a custom name to the "next()" > method: > L = el.iter() > Lnext = L.next > > It turns out: Inserting "N=loads(dumps(self))" helps if inserted after > the line Lnext = L.next, but it does not help when inserted before the > line. > > But how can this line interfere with my data? "el" is simply a list of > python ints! There is no instance of my extension class in it. > > This is what I can't understand. > > Any pointer to a tutorial on relevant debugging techniques is greatly > appreciated! This wiki page contains some pointers: http://wiki.sagemath.org/ValgrindingSage It might be outdated, though. Part of the release management process is that a release manager needs to valgrind Sage late in the release cycle. But I'm puzzled about which modules to valgrind. The Cythonized modules, the Python modules, etc? -- Regards Minh Van Nguyen --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---