Well, I was searching through the sources, and I think I might have figured out what MAY be happening. It seems that the full error is
consistency check failed: atom_string
And from looking at 'atom_string' (in 'm_atom.c'), it would appear that it can no longer determine the type of the atoms that are being returned from the database. Maybe something I did in splitting these files apart caused some weirdness.
Is it safe to assume that the name of the function that produces this error is the string just after the colon? In this case, "atom_string"?
Thank,
Mike
On Mon, Mar 23, 2009 at 6:08 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 23 Mar 2009, Mike McGonagle wrote:
Any suggestions about the "consistency check" issue? The only reference I see to them in the Pd source is in the 's_print.c' file, but that is just the function that gets called to report the error.
It could be any function that calls the bug() function. Here are three ways of finding causes:
- #define bug(A,B...) bug("%s:%d:"A,__FILE__,__LINE__,B) and recompile Pd.
This will cause every call to bug() to also report the file and line number where it was called from. You do it in <m_pd.h> but you need to #undef it where it is defined so that the function can be defined without a parse error.
- Use a debugger. In gdb, type "break bug" before you type "run". This will
make the programme pause at every call to bug(). Then use "where" to get a backtrace.
- Edit the bug() definition so that it posts a stacktrace as well. This is
OS-specific. In Linux, use the backtrace() and backtrace_symbols() functions from <execinfo.h>.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec