Custom Query (1030 matches)

A recent change to open-shared-library runs the code on the initial thread. The result of this is that if anything goes wrong (like the library not being found) the error is dumped to the AltConsole. This undermines CFFI's mechanism for finding shared libraries, which relies on open-shared-library being run within the dynamic context of a handler-case. It also seems like kind of a bad plan to dump an error to the AltConsole for something as common as not funding a shared library.

If we get an unrecoverable memory fault, we try to use the siginfo_t argument to the signal handler to describe the reason for the fault.

On Darwin, we handle exceptions at the Mach level and create the siginfo_t argument ourselves. I think that we do this to make the fault address easier to find, but I don't think that we set other fields in the siginfo_t to meaningful values, so the attempt to describe those fields often gives misleading results.

We should presumably either try harder to initialize the siginfo_t the way that a real SIGBUS or SIGSEGV would, or not trust our ability to describe the fault accurately.

I am using the trunk (1.6-dev-r14297M) on an Intel mac running 10.6.4.

After updating from SVN, I rebuild the IDE in two steps:

• Rebuild CCL with (rebuild-ccl ...)

• Build the IDE by running ccl -n and saying (require :cocoa-application).

The image dumped by the first of these steps never has ASDF in it (which is fine). The image dumped by the second of these steps *sometimes* has ASDF in it, which is at least annoying. Whether or not it contains ASDF depends on how much it needs to recompile, I think.

To replicate this: from the CCL root directory (whatever (translate-logical-pathname "ccl") gets), do this:

$ find cocoa-ide examples -name '*.dx64fsl' -exec rm {} \;

After this, the first time the IDE is build it will not include ASDF. The next time it will.

The problem is obviously related to how much needs to be compiled, but I've not been able to work out what exactly.