Lisp error: (wrong-type-argument vectorp bonk)

[Tim Cross]

This bug appears to be related to the recent changes in threading. This is taken from current vm trunk revision 889 taken today. Running under emacs 23.1

Opening a folder and attempting to read the first message gives

Debugger entered--Lisp error: (wrong-type-argument vectorp bonk)
  intern("<email address hidden>" bonk)
  vm-th-thread-symbol([[#<marker at 1 in unemail> #<marker at 73 in unemail> #<marker at 3047 in unemail> #<marker at 3225 in unemail> #<marker at 7700 in unemail> #<marker at 7701 in unemail>] ["1" " 1" nil #<marker at 1 in unemail Summary> #<marker at 89 in unemail Summary> <<>> <-- From_ "454" #<buffer unemail> nil nil nil nil nil nil [... ... "7bit" nil nil nil nil #<marker at 73 in unemail> #<marker at 3224 in unemail> #<marker at 3225 in unemail> #<marker at 7700 in unemail> nil <<c>> <<m>> nil nil nil] none #<overlay from 1 to 89 in unemail Summary> nil] [nil nil nil nil nil nil nil nil nil] ["4475" "Thursday" "22" "July" "2010" "22:42:48" "+1000" "NSW Lotteries Results Service" "<email address hidden>" "<email address hidden>" "142" "Open for Thursday's Powerball results" "^From:" "<email address hidden>" "<email address hidden>" "7" nil nil (number " " mark " NSW Lotteries Res Jul 22 142/4475 " thread-indent "\"Open for Thursday's Powerball results\"\n") nil nil nil nil nil nil nil] [nil <v> t nil nil t]])
  vm-th-thread-root([[#<marker at 1 in unemail> #<marker at 73 in unemail> #<marker at 3047 in unemail> #<marker at 3225 in unemail> #<marker at 7700 in unemail> #<marker at 7701 in unemail>] ["1" " 1" nil #<marker at 1 in unemail Summary> #<marker at 89 in unemail Summary> <<>> <-- From_ "454" #<buffer unemail> nil nil nil nil nil nil [... ... "7bit" nil nil nil nil #<marker at 73 in unemail> #<marker at 3224 in unemail> #<marker at 3225 in unemail> #<marker at 7700 in unemail> nil <<c>> <<m>> nil nil nil] none #<overlay from 1 to 89 in unemail Summary> nil] [nil nil nil nil nil nil nil nil nil] ["4475" "Thursday" "22" "July" "2010" "22:42:48" "+1000" "NSW Lotteries Results Service" "<email address hidden>" "<email address hidden>" "142" "Open for Thursday's Powerball results" "^From:" "<email address hidden>" "<email address hidden>" "7" nil nil (number " " mark " NSW Lotteries Res Jul 22 142/4475 " thread-indent "\"Open for Thursday's Powerball results\"\n") nil nil nil nil nil nil nil] [nil <v> t nil nil t]])
  vm-update-message-summary([[#<marker at 1 in unemail> #<marker at 73 in unemail> #<marker at 3047 in unemail> #<marker at 3225 in unemail> #<marker at 7700 in unemail> #<marker at 7701 in unemail>] ["1" " 1" nil #<marker at 1 in unemail Summary> #<marker at 89 in unemail Summary> <<>> <-- From_ "454" #<buffer unemail> nil nil nil nil nil nil [... ... "7bit" nil nil nil nil #<marker at 73 in unemail> #<marker at 3224 in unemail> #<marker at 3225 in unemail> #<marker at 7700 in unemail> nil <<c>> <<m>> nil nil nil] none #<overlay from 1 to 89 in unemail Summary> nil] [nil nil nil nil nil nil nil nil nil] ["4475" "Thursday" "22" "July" "2010" "22:42:48" "+1000" "NSW Lotteries Results Service" "<email address hidden>" "<email address hidden>" "142" "Open for Thursday's Powerball results" "^From:" "<email address hidden>" "<email address hidden>" "7" nil nil (number " " mark " NSW Lotteries Res Jul 22 142/4475 " thread-indent "\"Open for Thursday's Powerball results\"\n") nil nil nil nil nil nil nil] [nil <v> t nil nil t]])
  vm-update-summary-and-mode-line()
  vm-show-current-message()
  ad-Orig-vm-scroll-forward(nil)
  vm-scroll-forward(nil)
  call-interactively(vm-scroll-forward nil nil)

Note that the baktrace shows some advised functions i.e. ad-Orig-vm-scroll-forward, which are from emacspeak. Loading VM without emacspeak loaded gives the same error, so I don't believe it is relevant to the issue. Mention it only to avoid confusion or suspicion it is the advised functions contributing to the error.

Once you exit the backtrace, the message is displayed, but you get the same error when you move to the next message, so it doesn't appear to be message related. I'm using a minimal VM customization - leaving as much as possible to the default settings. However, I am using/loading vm-pcrisis. I have no config values relating to threading - using whatever the vm default settings are.

[Tim Cross (tcross)]

Just noticed the following in vm-vars.el

(defvar vm-thread-obarray 'bonk)
(defvar vm-thread-subject-obarray 'bonk)

and in vm-summary.el we have

    (setq vm-thread-obarray 'bonk
          vm-thread-subject-obarray 'bonk)

and in vm-folder.el, we have more setq for both vm-thread-obarray and vm-thread-subject-obarray

Not sure if this is at all relevant, but does seem a little unusual and a possible maintenance issue.

[Tim Cross (tcross)]

Looking into this more, it looks like the issue is that vm0thread-obarray needs to be a vector and that this check to ensure it is a vector is only performed in vm-thread.el. However, if you do not have threading enabled, which is the default, there is no check to ensure the variables have been initialized to be vectors.

I'm gusing that the variables are set to be the symbol 'bonk as a flag to ensure a new vector is created each time a folder is visited/updated and as 'bonk is not a vector, this will trigger the code in vm-threads.el that will update the variable to be a vector. If this is the case and since vm-threads only appears to be run if you have threading enabled, but that value is used in other areas, the test and initialization needs to be moved into either vm-summary or vm-folder. I would sugest abstracting the testing, creation, clearing of the variable so that it is more maintainable and robust against change.

[Uday Reddy (reddyuday)]

Hi Tim, what were the values of the threading-related variables when the error happened?

Cheers,
Uday

[Uday Reddy (reddyuday)]

Sorry, I mean what were the values of the *customization* variables. Don't worry about the internal variables.

Cheers,
Uday

[Uday Reddy (reddyuday)]

Never mind. I see the problem(s).

Cheers,
Uday

[Tim Cross (tcross)]

All thread related variables are at their default value. I use a VM
configuration for testing that is as close to vanilla as possible, only
setting variables necessary to work with my setup - mainly variables relating
to spool file location etc.

Setting the variable vm-summary-show-threads to t prevents the error. Its
default value is nil. It would seem the problem is a bug which assumes
threading is enabled.

Tim

> Sorry, I mean what were the values of the *customization* variables.
> Don't worry about the internal variables.
>

[Uday Reddy (reddyuday)]

Ok, thanks. It should be fixed now. (The trouble was that I was doing
all my testing with threading on, naturally :-)

Cheers,
Uday

[Tim Cross (tcross)]

Confirming that the fix appears to have worked.