Le 2011-11-15 à 22:03:00, Ivica Ico Bukvic a écrit :
I have not been following this thread at all, but for what it's worth in
my experience these kinds of seemingly illogical errors usually arise
from memory corruption (typically because something has not been
properly allocated).
That's why I go on and on about Valgrind and its magical abilities to find
causes instead of consequences.
But I should also remark that code is easier to debug when it's not
optimised :
#1 0x000000000043c629 in pd_typedmess (x=0x830220, s=<optimized out>,
argc=<optimized out>, argv=<optimized out>) at m_class.c:812
as you can see, we're losing information, because the executable does
stuff in a way that gdb doesn't understand, and some info is missing about
how gdb could be reading it, when it's readable at all. Some variables
disappear entirely, some only pretend to.
But more importantly, some function calls disappear, either because they
are merged (due to any options named «inline»), or because it's faster to
skip doing certain things that are required for producing good backtraces
(«omit-frame-pointer» also means some function calls become hidden).
______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
