Custom Query (1030 matches)

I have the following error:

? (rem (expt 2 43112609) 1000000000000000)
> Error: DIVISION-BY-ZERO detected
> While executing: CCL::%FLOOR-99, in process listener(1).

and

? (rem (expt 2 43112609) 400000000000000500)
> Error: DIVISION-BY-ZERO detected
> While executing: CCL::%FLOOR-99, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > (rem (expt 2 43112609) 400000000000000500)
exception in foreign context
Exception occurred while executing foreign code
 at mark_root + 45
? for help
[31584] OpenMCL kernel debugger: b
current thread: tcr = 0xb7c57aa0, native thread ID = 0x7b60, interrupts enabled


Bogus  frame b7af2950
[31584] OpenMCL kernel debugger: l
%ebx (arg_z) = -302950275
%esi (arg_y) = #<header ? #x0805F7E7>
------
%edi (fn) = -1776
------
zsh: segmentation fault  ./lx86cl

I have the same environment as in the ticket:338

On Fedora 9/PPC, /usr/include/asm/ioctl.h contains:

/* provoke compile error for invalid uses of size argument */
extern unsigned int __invalid_size_argument_for_IOC;
#define _IOC_TYPECHECK(t) \
	((sizeof(t) == sizeof(t[1]) && \
	  sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
	  sizeof(t) : __invalid_size_argument_for_IOC)

/* used to create numbers */
#define _IO(type,nr)		_IOC(_IOC_NONE,(type),(nr),0)
#define _IOR(type,nr,size)	_IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOW(type,nr,size)	_IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))

and some ioctl constants are then defined in terms of _IOR(), _IOW(), etc.

The conditional expression in the expansion of _IOC_TYPECHECK (and possibly the reference to the variable) cause the FFI parser to give up, so some IOCTL constants aren't defined.

We can either try to be more ambitious and interpret the expansion (it should always expand to "sizeof(t)" unless there's an error in the header file) or do all macroexpansion as if:

#define _IOC_TYPECHECK(t) sizeof(t)

was predefined and not overridden by the definition in the header file.

(We might be able to translate this particular macro into something that we can make sense of, but we can't always do that, so it seems like a mechanism for dealing with intractable nonsense would be desirable.)

Found this working with r10913 Linuxx8664:

value #<recursive-lock [ptr @ #x6D51C0] #x3000448438ED> is not of the expected type
ccl:read-write-lock.

​A full backtrace.

This only happens with at least 46 eql-specialized methods; ​the test code and results of running. That trial shows it also on r10956.

Only eql-specialized methods with the same preceding specializers count; commenting out the loop that adds methods specialized on another class has no effect on the test results; it's still 46.

Setting ccl::*lock-free-hash-table-default* to NIL before calling the generic function fixes the problem (found while browsing r10867).