Good points, I forgot that it was an illegal instruction exception when I wrote that. Getting a core dump is probably the best route to getting this information.
A quick search reveals that the following command can be run from an OSX Terminal prior to executing the application (which should also be executed from the same Terminal in order for the command to take effect): ulimit -c unlimited The resulting core file will be found at: /cores/core.PID where PID is the process ID. Element On Mon, Aug 19, 2013 at 6:49 PM, R.L. Horn <li...@eastcheap.org> wrote: > On Mon, 19 Aug 2013, Element Green wrote: > > I've often found that the glib memory slice subsystem can be sensitive to >> memory corruption. It could be that there is some other unrelated memory >> corruption going on which is causing this. >> > > In that case I'd expect a segfault before anything could intrude on > instruction space. File corruption seems a more likely suspect. > > I still think GCC is simply generating an instruction that the build > system knows about and the host doesn't, though it's hard to imagine what > that would be (pclmulqdq?). Obviously, it would help enormously if we knew > exactly what triggered the SIGILL. > > > ______________________________**_________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/**mailman/listinfo/fluid-dev<https://lists.nongnu.org/mailman/listinfo/fluid-dev> >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
