[PD-dev] Externals with interdependancies

[Mike McGonagle]

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 at 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:
>
> 1. #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.
>
> 2. 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.
>
> 3. 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



-- 

Charles Kettering  - "My interest is in the future because I am going
to spend the rest of my life there."