It's very likely that your bug is not deterministic, but is rather related to random details of execution timings and/or memory layouts. Both of those things are different when you change architectures or change optimization levels. The changes do not themselves introduce an error, they merely change run-time conditions so that an existing error is revealed.
The number one suspect in this kind of crash is a memory management bug. You have an idea where to look (in libpd, which I assume is your code, too), and what it's doing (loading data from a file?). So I suggest you poke around in the logic of that operation.
Also, based on the function names, it looks like you're loading numerical data, perhaps in vectors or arrays. Code like that is very prone to buffer overflow coding bugs, and those too will produce different failures depending on architecture or optimization. (In some cases, the overflow data might be written into an unused area at the end of a struct, which won't normally cause a crash.)
Finally, this is a very specific problem case, but it might apply if this code is Obj-C and using methods that return a struct (which seems possible if you're decoding structured numeric data). It is NOT safe to use such methods with a nil receiver, even though sending messages to nil is otherwise safe in Obj-C. The outcome of doing so is a random memory corruption, which may or may not cause a crash, depending what's overwritten. It's not likely that this is your problem, but it's worth thinking about, since I know from experience that it's a very difficult bug to find if you're not looking for it.