stack overflow error on library load

Tue Dec 20 13:25:22 UTC 2016

You could try without SLIME, from the bare REPL. Not that SLIME breaks
anything, but maybe you'll get a more understandable stack trace.

On 20 December 2016 at 14:14, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:

>
>
> On Tue, Dec 20, 2016 at 6:17 AM Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>
>> Could it be some path-related problem (e.g. spaces in the path, a very
>> long path, unusual characters in the path, ...)?
>>
>
> On my system the path to vecto is c:\Users\977314\quicklisp\...  There are
> not spaces in the path.
>
> vecto depends on cl-vectors, zpng, zpb-ttf.  I can load all of them
> without problem.
>
> Example of paths:
>
> ; SLIME 2.18
> CL-USER> (asdf:system-source-directory :cl-vectors)
> #P"C:/Users/977315/quicklisp/dists/quicklisp/software/cl-
> vectors-20150407-git/"
> CL-USER> (asdf:system-source-directory :vecto)
> #P"C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/"
> CL-USER>
>
> If vecto.asd contains dependencies to those three libraries, the asd will
> load.  Once I add a file to the list of components, it fails.
>
> Mirko
>
>
>>
>> On 18 December 2016 at 23:23, Mirko Vukovic <mirko.vukovic at gmail.com>
>> wrote:
>>
>> Hello again,
>>
>> I have joined the mailing list, and also seen Mark Evenson's reply
>> https://mailman.common-lisp.net/pipermail/armedbear-devel/
>> 2016-December/003759.html.
>> It is encouraging that he can load Vecto.
>>
>> A few more details on my environment and more probing results
>>
>> Implementation details:
>>
>> CL-USER> (lisp-implementation-version)
>> "1.4.0"
>> "Java_HotSpot(TM)_Client_VM-Oracle_Corporation-1.7.0_51-b13"
>> "x86-Windows_8-6.2"
>>
>> Does the above look OK?  Version wise, it is close to what Mark has,
>> except that he has
>> JDK, and I have Java_HotSpot.
>>
>> ASDF Version:
>>
>> I was wondering if the issue had to do with ASDF's looking for libraries
>> and files, i.e., whether
>> I was hit by an ASDF bug.  So I installed the latest ASDF moving from
>> 3.1.7, to 3.1.7.43,
>> (which is a release candidate for asdf 3.2)
>>
>> The stack overflow remains.
>>
>> Manual loading of dependencies (libraries and files):
>>
>> I verified that I can manually load all the libraries vecto depends on,
>> and also manually
>> compile and load all of its component files.
>>
>> Isolate bug by dividing up the ASDF file:
>>
>> To investigate further, I started commenting out parts of Vecto's asdf
>> file.  As long as the components
>> list is empty, asdf will load Vecto.
>> (asdf:defsystem #:vecto
>>   :depends-on (#:cl-vectors
>>                #:zpng
>>                #:zpb-ttf)
>>   :version "1.4.10"
>>   :author "Zach Beane <xach at xach.com>"
>>   :description "Create vector graphics in PNG files."
>>   :license "BSD"
>>   :components ())
>>
>> But adding a file to the components list will cause stack overflow.  For
>> example
>> this will cause stack overflow:
>>
>> (asdf:defsystem #:vecto
>>   :depends-on (#:cl-vectors
>>                #:zpng
>>                #:zpb-ttf)
>>   :version "1.4.10"
>>   :author "Zach Beane <xach at xach.com>"
>>   :description "Create vector graphics in PNG files."
>>   :license "BSD"
>>   :components ((:file "package")))
>>
>>
>>
>>
>>
>> On Wed, Dec 14, 2016 at 8:54 AM Mirko Vukovic <mirko.vukovic at gmail.com>
>> wrote:
>>
>> See below:
>>
>> On Tue, Dec 13, 2016 at 10:45 PM Mirko Vukovic <mirko.vukovic at gmail.com>
>> wrote:
>>
>> Hello,
>>
>> I have installed ABCL 1.4 on Windows 10 and Java 1.7.
>>
>> When loading some libraries, I get a stack overflow error.
>>
>> For example loading vecto fails
>>
>> vecto passes the cl-test-grid on linux (see
>> https://common-lisp.net/project/cl-test-grid/library/vecto.html)
>>
>>
>> I did a bit more probing to try and isolate the cause of the overflow:
>>
>>    - ASDF file manually loads and compiles
>>    - I could manually load all the pre-requisite libraries
>>    - I could manually compile and load all the lisp files
>>
>> Looking at the error message in frame 8 (see below), the cause may be
>> in the slime/swank interaction with abcl.
>>
>> I may take this up at the slime mailing list.
>>
>>
>>
>> Running
>> (asdf:load-system :vecto)
>>
>> Gives:
>> Stack overflow.
>>    [Condition of type STORAGE-CONDITION]
>>
>> Restarts:
>>  0: [*ABORT] Return to SLIME's top level.
>>  1: [ABORT] Abort thread.
>>
>> Backtrace:
>>   0: (#<FUNCTION {BEB670}> #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION
>> {BEB670}>)
>>   1: (APPLY #<FUNCTION {BEB670}> (#<STORAGE-CONDITION {14AA1B6}>
>> #<FUNCTION {BEB670}>))
>>   2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION
>> {14AA1B6}> #<FUNCTION {BEB670}>)
>>   3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {14AA1B6}>)
>>   4: org.armedbear.lisp.Lisp.stackError(Lisp.java:388)
>>   5: org.armedbear.lisp.swank_513.execute(swank.lisp:1677)
>>   6: org.armedbear.lisp.LispThread.execute(LispThread.java:851)
>>   7: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800)
>>   8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system
>> :vecto)
>>      ") "COMMON-LISP-USER" 9)
>> etc
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20161220/1391a0d4/attachment-0001.html>