"incorrect number of arguments" reported as "not a function"

[Michael D. Adams]

I can reliably reproduce the following bug on my machine and batman.cs.indiana.edu, but I'm unsure
how well this bug will port to other machines.

To produce the bug create a Makefile with a single target.
$ cat Makefile
default:
        ikarus --r6rs-script not_proc.ss

Also create a small scheme script.
$ cat not_proc.ss
(import (ikarus))

(let ((f (lambda (i) 1))
      (m (* 1 1))
      (e (* 1 1)))
  (make-bytevector 64000000 0)
  (f 1 2) ; This should be an "incorrect number of argument" error, but it is a "not a procedure"
  (+ e m))

Then when you run 'make' the following error is reported.
$ make
ikarus --r6rs-script not_proc.ss
unhandled exception:
 Condition components:
   1. &error
   2. &who: apply
   3. &message: "not a procedure"
   4. &irritants: #()
make: *** [default] Error 252

This should be an "incorrect number of arguments" error instead of "not a procedure".
Also for some reason the irritants "list" somehow became a vector.

Note that this only happens when ikarus is invoked from "make" and
any simpler version of not_proc.ss no longer triggers the bug.

[Abdulaziz Ghuloum (aghuloum)]

Interesting. I'm currently trying this at the repl:

$ rlwrap ikarus -b ikarus.boot
Ikarus Scheme (Build 2007-11-06)
Copyright (c) 2006-2007 Abdulaziz Ghuloum

> (begin (make-bytevector 64000000 0) 12)
Unhandled exception
 Condition components:
   1. &error
   2. &who: apply
   3. &message: "not a procedure"
   4. &irritants: (#<unknown EAADFD.7>)
> (begin (make-bytevector 64000000 0) 12)
12

As you can see, it fails the first time, but passes the second time.
My best hypothesis at this time is that there is a cache coherency problem: somewhere inside the system, a *procedure* is called, but its pointer is messed up so it shows up as a vector in your system and as a garbage #<unknown> in mine. Calling the same procedure the second time succeeds since the cache is now flushed (a side effect from the first call).

I remember removing some calls to mprotect some time last week when I was porting to cygwin. It might be the cause.
Will investigate further.

Thanks.

Aziz,,,

[Abdulaziz Ghuloum (aghuloum)]

Fixed in revision 996.

Just in case you're interested:
    - The real reason was in the register allocator, where one live
      variable (the memmory size of the bytevector) was not marked live
      across the call to do-overflow. When the overflow returned, the
      value of that variable (which was in the %ebx register) was
      trashed, leading to an incorrect bump in the allocation pointer.
    - Note to self, never blame anything on cache coherency again!

[Abdulaziz Ghuloum (aghuloum)]

This bug report is about to be closed as the fix comitted previously
will be incorporated in the next 0.0.2 release of Ikarus Scheme,
scheduled for November 28, 2007.
A release candidate tarball is available for download from:
  http://www.cs.indiana.edu/~aghuloum/ikarus/ikarus-0.0.2-rc1.tar.gz
Please do test it if you have the time and report any issues you
might encounter. Thank you very much for your support. Aziz,,,
(Sorry for the duplicates; I'm updating every open bug.)