Custom Query (1030 matches)
Results (577 - 579 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #743 | invalid | ccl::foreign-type-alignment returns incorrect alignment for :[un]signed-doubleword on x86 | ||
| Description |
Using 1.6-dev-r14265M-trunk (LinuxX8632):
The correct value is 32 |
|||
| #744 | fixed | Describing memory faults in Darwin | ||
| Description |
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. |
|||
| #745 | fixed | Building COCOA-APPLICATION only sometimes causes ASDF to be loaded | ||
| Description |
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:
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 $ 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. |
|||
