stack overflow error on library load

[Alessio Stalla]

Could it be some path-related problem (e.g. spaces in the path, a very long
path, unusual characters in the path, ...)?

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/16239d34/attachment.html>