headers
Eric Marsden | 1 Nov 2008 12:55
Picon
Favicon

Compilation triggers jvm stack inconsistency

Hi,

Compiling the following code triggers a stack inconsistency error in
ABCL. Note that the bug is difficult to trigger: the UNWIND-PROTECT is
necessary, as are the inline declaration and the call from an
undefined function. 

(defun foo ()
  (flet ((bar () (unwind-protect 1 2)))
    (declare (inline bar))
    (undefined (bar))))

,----
| CL-USER(2): (compile-file "a")
| ; Compiling /home/emarsden/a.lisp ...
| ; (IN-PACKAGE :CL-USER)
| ; (DEFUN FOO ...)
| Stack inconsistency at index 24: found 3, expected 1.
| java.lang.VerifyError: (class: org/armedbear/lisp/a_1, method: execute signature:
()Lorg/armedbear/lisp/LispObject;) Inconsistent stack height 1 != 3
| 	at java.lang.Class.getDeclaredConstructors0(Native Method)
| 	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
| 	at java.lang.Class.getConstructor0(Class.java:2716)
| 	at java.lang.Class.getConstructor(Class.java:1674)
| 	at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1135)
| 	at org.armedbear.lisp.Lisp.loadCompiledFunction(Lisp.java:1062)
| 	at org.armedbear.lisp.CompiledFunction$1.execute(CompiledFunction.java:174)
| 	at org.armedbear.lisp.Symbol.execute(Symbol.java:708)
| 	at org.armedbear.lisp.LispThread.execute(LispThread.java:626)
| 	at org.armedbear.lisp.compile_file_4.execute(compile-file.lisp:51)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Huelsmann | 1 Nov 2008 22:29
Picon
Gravatar

Re: Fifth iteration for new build.xml

On Wed, Oct 8, 2008 at 8:20 AM, Mark Evenson <evenson <at> panix.com> wrote:
> Attached please find a new diff against [common-lisp svn trunk][1], which
> may be viewed incrementally to previous patches via [abcl-dynamic-install
> trunk][2].
>
> This patch uses the Ant 'uptodate' task to determine whether to compile
> system fasls.  On a system where invoking the JVM is slow this can result in
> substantial speedups if you are developing the Java side of ABCL as opposed
> to the Lisp.
>
> From the work in getting the dependencies correct, it seems that there are a
> fair number of Lisp files that could be moved out of the core
> org.armedbear.lisp package, like the swank related files that I don't think
> are really used at this point.

I worked out that we indeed could remove a very large number of .lisp
files out of the JAR:

There were a large number of files which aren't required at all (but
you already knew that). I reduced the required files to "package.lisp,
print-object.lisp, boot.lisp, autoloads.lisp".

Then, I found that I could even further reduce the number of required
.lisp files in the JAR to 1 (!): boot.lisp. It's probably possible to
even reduce it further, but just replacing "boot.lisp" with
"boot.abcl" throughout the sources didn't get me a running system.

Anyway, this just shaved off approximately 350kB off the abcl.jar file (~ 5%).

Bye,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Evenson | 2 Nov 2008 10:50
Picon
Favicon

Still need 'with-mutex.lisp'

Erik Huelsmann wrote:
[…]
> I worked out that we indeed could remove a very large number of .lisp
> files out of the JAR:
[…]
> Then, I found that I could even further reduce the number of required
> ..lisp files in the JAR to 1 (!): boot.lisp. It's probably possible to
> even reduce it further, but just replacing "boot.lisp" with
> "boot.abcl" throughout the sources didn't get me a running system.

It looks like we still need 'with-mutex.lisp' in order for SLIME from 
CVS HEAD to work.  Why this is the case for the WITH-MUTEX macro, and 
not the other forms doesn't make sense to me.

The (trivial) patch for this in the new Trac [ticket][19].

[19]: http://trac.common-lisp.net/armedbear/ticket/19

--

-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Permalink | Reply | 2 comments |
headers
Erik Huelsmann | 2 Nov 2008 12:37
Picon
Gravatar

Re: Still need 'with-mutex.lisp'

On Sun, Nov 2, 2008 at 10:50 AM, Mark Evenson <evenson <at> panix.com> wrote:
> Erik Huelsmann wrote:
> […]
>>
>> I worked out that we indeed could remove a very large number of .lisp
>> files out of the JAR:
>
> […]
>>
>> Then, I found that I could even further reduce the number of required
>> ..lisp files in the JAR to 1 (!): boot.lisp. It's probably possible to
>> even reduce it further, but just replacing "boot.lisp" with
>> "boot.abcl" throughout the sources didn't get me a running system.
>
> It looks like we still need 'with-mutex.lisp' in order for SLIME from CVS
> HEAD to work.  Why this is the case for the WITH-MUTEX macro, and not the
> other forms doesn't make sense to me.

Thanks for testing the change. I think it shows a flaw in the general
design of compile-system.lisp. Because, it's not the fact that it
should actually be added to the jar which is the real problem, it's
the fact that compile-system doesn't compile it into an abcl file.
I've changed compile-system.lisp in r11374.

If you could test that one again, please and possibly adjust ticket 19
for the result?

>
> The (trivial) patch for this in the new Trac [ticket][19].
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Evenson | 2 Nov 2008 15:55
Picon
Favicon

Re: Still need 'with-mutex.lisp'

Erik Huelsmann wrote:

> Thanks for testing the change. I think it shows a flaw in the general
> design of compile-system.lisp. Because, it's not the fact that it
> should actually be added to the jar which is the real problem, it's
> the fact that compile-system doesn't compile it into an abcl file.
> I've changed compile-system.lisp in r11374.

With your commit to r11374, SLIME CVS HEAD now runs.

I attached a further patch to ticket 19 to adjust the files used in 
computing the FASLs uptodate target.

--

-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Permalink | Reply | 0 comments |
headers
Mark Evenson | 2 Nov 2008 19:01
Picon
Favicon

One additional patch for SLIME ticket #7

An additional (second) patch to tighten the build system after the 
removal of the obsolete SLIME in ABCL has been [attached to ticket 7][1].

[1]: 
http://trac.common-lisp.net/armedbear/attachment/ticket/7/remove-slime-build.patch

--

-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Permalink | Reply | 0 comments |
headers
Mark Evenson | 3 Nov 2008 08:05
Picon
Favicon

Re: Compilation triggers jvm stack inconsistency

Eric Marsden wrote:
> Hi,
> 
> Compiling the following code triggers a stack inconsistency error in
> ABCL. Note that the bug is difficult to trigger: the UNWIND-PROTECT is
> necessary, as are the inline declaration and the call from an
> undefined function. 
> 
> (defun foo ()
>   (flet ((bar () (unwind-protect 1 2)))
>     (declare (inline bar))
>     (undefined (bar))))

Logged as [ticket 21][1].

[1]: http://trac.common-lisp.net/armedbear/ticket/21

Thanks for the bug report!

Mark <evenson <at> panix.com>

--

-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 4 Nov 2008 21:35
Picon
Gravatar

Re: Availability of Trac

2008/11/1 Hideo at Yokohama <hideo.at.yokohama <at> gmail.com>:
>
> I took a look at the tickets. Thanks for adding them!
>
> For #13 I looked at FileStream.java . If the _setFilePosition is required
> even for
> character streams, I think there is no easy and safe way to implement
> multiple
> encoding handling.
> But since abcl can read from network connections, on which you can't do
> random access,
> I believe there is a way to keep the seeking requirement out of the way of
> character (non-binary) streams.

I added comments to ticket # 13; I think we could use FileInputStream:
it supports a SeekableChannel interface which allows getting and
setting of the file position. What would you think about that
solution?

Bye,

Erik.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Permalink | Reply | 13 comments |
headers
Hideo at Yokohama | 5 Nov 2008 16:27
Picon

Re: Availability of Trac

Hi.  Thanks for your time investigating.

Are you talking about java.io.FileInputStream ? Or is it a lisp thing?
I've never heard of a SeekableChannel, and could not grep it in the abcl  
source.
(SeekableChannel seems to be a C++ thing, according to Google)

If you are talking about the one in JDK, here is my comment :

Character code conversion is implemented in InputStreamReader and  
OutputStreamWriter.
To support multiple byte encodings both directions of converters have to  
maintain some
state (i.e. it must have some amount of buffer).
So you cant safely seek the underlying stream to a different position.

As a result, JDK Readers and Writers (which are character oriented, rather  
than byte oriented)
don't provide seeking functions.  For java.io.Reader classes, the closest  
thing to seek is the
'mark' functionality. You can tell the stream to 'mark' the current  
position, i.e. remember the
current file pos, then read some data, then tell the stream to rewind to  
the position that was marked.
The mark function doesn't tell you what the current byte offset is. It  
just remembers.
You can't give an arbitrary integer to a Reader and tell it to seek to  
that position.

In the lisp world, with my limited lisp knowledge, I guess the safe way to
(Continue reading)

Permalink | Reply | 12 comments |
headers
Erik Huelsmann | 5 Nov 2008 21:26
Picon
Gravatar

Re: Availability of Trac

On Wed, Nov 5, 2008 at 4:27 PM, Hideo at Yokohama
<hideo.at.yokohama <at> gmail.com> wrote:
> Hi.  Thanks for your time investigating.
>
> Are you talking about java.io.FileInputStream ? Or is it a lisp thing?
> I've never heard of a SeekableChannel, and could not grep it in the abcl
> source.
> (SeekableChannel seems to be a C++ thing, according to Google)

I see I was talking about SeekableByteChannel, which is in the JDK (as
of 1.4, I think).

>
> If you are talking about the one in JDK, here is my comment :
>
> Character code conversion is implemented in InputStreamReader and
> OutputStreamWriter.
> To support multiple byte encodings both directions of converters have to
> maintain some
> state (i.e. it must have some amount of buffer).
> So you cant safely seek the underlying stream to a different position.

hrm. ok. I understand what you're saying. It's a bit disappointing,
but I guess it works for the Java world.

There's one other option though, possibly: record how many characters
have been read, using a filtering stream. and implementing a .skip()
function which skips exactly the number of required characters.

> As a result, JDK Readers and Writers (which are character oriented, rather
(Continue reading)

Permalink | Reply | 11 comments |

Gmane