GNU bug report logs - #31742
26.1.50; excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1

Previous Next

Full log

View this message in rfc822 format

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31742 <at> debbugs.gnu.org
Subject: bug#31742: 26.1.50; excorporate.elc byte-compiled in Emacs 25.x fails in Emacs 26.1
Date: Thu, 07 Jun 2018 21:13:34 -0400

Noam Postavsky <npostavs <at> gmail.com> writes:

> On 7 June 2018 at 10:06, Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
>
>> Yes, but the error that produces the backtrace happens much later
>> via a different entry point, M-x exco-calendar-show-day:
>>
>> Debugger entered--Lisp error: (wrong-type-argument soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding"))
>>   signal(wrong-type-argument (soap-binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")))
>>   soap-find-operation(#s(soap-port :name "ExchangeServicePort" :namespace-tag nil :service-url "https://redacted/ews/exchange.asmx" :binding ("http://schemas.microsoft.com/exchange/services/2006/messages" . "ExchangeServiceBinding")) "FindItem")
>
>> The initial problem in exco--bind-wsdl (via the M-x excorporate entry
>> point) does not throw an error.  Basically, in the failure case, parsing
>> of the WSDL XML is incomplete, and the later error is due to that.
>
> Right, if I just evaluate the following in 26.1 without any 25.1
> bytecode I get a similar error:
>
> (let ((port (make-soap-port
>          :name "ExchangeServicePort"
>          :namespace-tag nil
>          :service-url "https://redacted/ews/exchange.asmx"
>          :binding
> '("http://schemas.microsoft.com/exchange/services/2006/messages"
>             . "ExchangeServiceBinding"))))
>   (soap-find-operation port "FindItem"))
>
> I don't quite understand how it's supposed to work successfully
> though. Is there a way to see it working without having to run a
> server on the other end (i.e., can you give some elisp forms to
> evaluate that make the above work)?
>
> I'm guessing the problem is with some old and new structs not matching
> according to `equal' and/or `sxhash', which cl-old-struct-compat-mode
> doesn't do anything about.

I did some more narrowing and found that the issue is with the use of
symbol properties in soap-resolve-references.  I added debugging:

(defun soap-resolve-references (element wsdl)
  "Replace names in ELEMENT with the referenced objects in the WSDL.
This is a generic function which invokes a specific resolver
function depending on the type of the ELEMENT.

If ELEMENT has no resolver function, it is silently ignored."
  (when (equal (soap-element-name element) "ExchangeServicePort")
    (message "1: %s" element)
    (message "2: %s" (aref element 0))
    (message "3: %s" (get (aref element 0) 'soap-resolve-references)))
  (let ((resolver (get (aref element 0) 'soap-resolve-references)))
    (when resolver
      (funcall resolver element wsdl))))

In the working case, I get:

1: #s(soap-port ExchangeServicePort nil https://mail.cisco.com/ews/exchange.asmx (http://schemas.microsoft.com/exchange/services/2006/messages . ExchangeServiceBinding))
2: soap-port
3: soap-resolve-references-for-port

while in the failing case, I get:

1: [cl-struct-soap-port ExchangeServicePort nil https://mail.cisco.com/ews/exchange.asmx (http://schemas.microsoft.com/exchange/services/2006/messages . ExchangeServiceBinding)]
2: cl-struct-soap-port
3: nil

This means the resolver fails to run and the ExchangeServicePort element
is not expanded, which results in exco-calendar-show-day's subsequent
failure.

It seems like soap-client's use of symbol properties is not safe across
major Emacs versions.

Thomas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.