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

Bug #160483 reported by Michael D. Adams on 2007-11-06
Affects Status Importance Assigned to Milestone
Ikarus Scheme
Abdulaziz Ghuloum

Bug Description

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
        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) wrote :

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)

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.



Changed in ikarus:
assignee: nobody → aghuloum
importance: Undecided → Critical
status: New → Confirmed
Abdulaziz Ghuloum (aghuloum) wrote :

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!

Changed in ikarus:
status: Confirmed → Fix Committed
Abdulaziz Ghuloum (aghuloum) wrote :

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:
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.)

Changed in ikarus:
milestone: none → 0.0.2
Changed in ikarus:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers