D(B)u(g)ck Hunting Season is opened!

[pjot]

Hi,



With the 9.1 release approaching, it might be a nice challenge to see if there are any bugs left in the newLisp interpreter. Probably not, but who knows!



Rules:

When a bug can be reproduced in the latest newLisp release (currently 9.0.18) it will be acknowledged as a bug.[/list]

The Bug Hunting Season starts as of today and will end at february 5.[/list]

Bugs in the documentation will not be rewarded.[/list]

Anybody who finds 3 bugs or more will be rewarded with eternal fame and a special gift (to be determined).[/list]

The final judge on the question whether a found bug is really a bug, will be Lutz, of course.



Please post all your bugs as a reply to this thread.



Let the bug hunting begin!



Peter

[newdep]

BUG#  POP



9.0.18 release ->



The integer is passing beyond end of string..and even beyond "00"

(a 'nil is expected here)



Some linux version do give this warning but some just SegmentFault.

OS2 does a crash dump.





> (setq t "1")

"1"

> (pop t -1)

"1"

> (pop t -1)

"00"

> (pop t -1)



not enough memory in function pop

> (pop t -1)



not enough memory in function pop

> (pop t -1)



not enough memory in function pop

>

[pjot]

At least this is inconsequent behaviour, as it does not happen with lists:

> (set 'q '(1 2 3 4))

(1 2 3 4)

> q

(1 2 3 4)

> (pop q -4)

1

> (pop q -4)

2

> (pop q -4)

3

> (pop q -4)

4

> (pop q -4)

nil

> (pop q -4)

nil

When the list is empty, the (pop) returns a 'nil'.



Peter

[newdep]

BUG# quoted text and 2048 limit



newlisp-9.0.18 ->



"00" is not automaticly converted to [text] [/text] when it passed the

boundery of 2048, whereas other strings are..



This works ->



(dup "bug" 2049)

(dup {00} 2049)



and this not ->



(dup "00" 2049)

(returns -> [text][/text])





Im not 100% sure if this is a bug or behaviour... for "00"

[pjot]

Indeed a (dup "00" 20) works but the 2049 boundary is never passed... strange...???

> (dup "00" 20)

"0000000000000000000000000000000000000000"

> (dup "00" 2049)

[text][/text]

I seems Lutz will be busy ;-)

[newdep]

Its about auto conversion from "" to [text][/text].. Im not sure if its a bug..

[Lutz]

The buffer gets created correctly, but because the return value is > 2048 characters it will get displayed with [text],[/text] tags, but the text tags display a string in original without escaping binary characters as it occurs in strings displayes with quotes:

Code Select Expand

>  (set 'big (dup "00" 3000))
[text][/text]
> (length big)
3000
> (0 20 big)
"0000000000000000000000000000000000000000"
> (2980 20 big)
"0000000000000000000000000000000000000000"
>


I would say: not a bug.

I seems Lutz will be busy ;-)

I hope so :-), better to find them now than after the release. I throw in a T-shirt for the winner.



Lutz

[pjot]

Probably not to be qualified as a bug, but worth mentioning. In the "CHANGES-9.0.1-18.txt" we can read:

new -w <working> commandline switch

However, when we run 'newlisp -h' this option is not yet mentoned:

peter[~]$ newlisp -h



newLISP v.9.0.18 Copyright (c) 2007 Lutz Mueller. All rights reserved.



usage: newlisp [file ...] [options ...] [file ...]



options:





 -h this help

 -s <stacksize>

 -m <max>

 -l log connections only

 -L log all

 -p <port>

 -d <port>

 -e <quoted>

 -c no prompts, HTTP

 -C force prompts

 -http HTTP only

Peter

[pjot]

NewLisp in Linux segfaults with the following scenario.



First, start newLisp in daemon mode.

peter[~]$ newlisp -c -d 8080

Now, from another terminal, telnet to port 8080. Then press the standard '<CTRL> ]' and then 'q' to quit the telnet connection again.

peter[~]$ telnet localhost 8080

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

^]



telnet> q

Connection closed.

peter[~]$

Now go back to the first terminal and press <CTRL>+C to quit the newLisp daemon.

peter[~]$ newlisp -c -d 8080

Segmentation fault

peter[~]$

Peter

[pjot]

The (seek) function returns any position (Linux).



Create a file of a few bytes.

echo "blabla" > file.txt

Now open this file in newLisp and check the last position.

> (open "file.txt" "r")

5

> (seek 5 -1)

7

Obviously, the file contains 7 bytes, namely, the letters "blabla" and a newline. In the manual the following is mentioned:

Sets the file pointer to the new position int-position in the file specified by int-file. The new position is expressed as an offset from the beginning of the file, 0 (zero) meaning the beginning of the file. If no int-position is specified, seek returns the current position in the file.

The strange thing is, we can put the position in the file anywhere, even after the 7 bytes.

> (seek 5 8)

8

> (seek 5)

8

> (seek 5 20)

20

> (seek 5)

20

> (seek 5 -1)

7

A (seek) with -1 returns the last position correctly, though. Also the manual mentions:

On failure, seek returns nil.

But the only time a seek fails, is with numbers lower than -1.

> (seek 5 -100)

nil

> (seek 5 -2)

nil

Numbers larger than 0 all succeed and return a non-existing position.



Peter

[pjot]

Sorry to disturb you again, but now I found issues with (file-info).



ISSUE #1. Symlinks



Create a symlink to a file and check the sizes.

peter[~]$ ln -s file.txt file.lnk

peter[~]$ ls -l

lrwxrwxrwx  1 peter users          8 2007-01-25 21:55 file.lnk -> file.txt

-rw-r--r--  1 peter users          7 2007-01-25 21:32 file.txt

peter[~]$

As you can see, the size of the symlink is 8 bytes, while the size of the file is 7 bytes. Now run (file-info) on the symlink.

> (file-info "file.lnk")

(7 41471 0 1000 100 1169762126 1169762125 1169762125)

Instead of the size of the symlink, the size of the pointed file is returned. While at the same time the modefield expresses a symlink.





ISSUE #2. Pipe files.



Create a pipe file.

peter[~]$ mkfifo file.pipe

peter[~]$

Now run (file-info) on this file.

> (file-info "file.pipe")

That's right! In this situation, the (file-info) never returns.



Peter

[pjot]

Sequence does not show 0.0 (Linux)



The (sequence) command does not show a '0.0' in the following situation.

> (sequence 1.0 -1.0 -0.1)

(1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 -5.551115123e-17 -0.1 -0.2

 -0.3 -0.4 -0.5 -0.6 -0.7 -0.8 -0.9 -1)

One should expect a genuine '0.0' instead of the extreme low unrounded value -5.551115123e-17....



The manual mentions:

Note that the step size must be a positive number, even if sequencing from a higher to a lower number.

So there is no error warning, or is the '-0.1' treated as a positive number? Anyway, a positive '0.1' also has the same issue.

> (sequence 1.0 -1.0 0.1)

(1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 -5.551115123e-17 -0.1 -0.2

 -0.3 -0.4 -0.5 -0.6 -0.7 -0.8 -0.9 -1)

> (sequence 1.1 -1.2 0.1)

(1.1 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 2.775557562e-17 -0.1 -0.2

 -0.3 -0.4 -0.5 -0.6 -0.7 -0.8 -0.9 -1 -1.1 -1.2)

Peter

[newdep]

I though you already had a T-shirt? ;-)

[pjot]

Hi Lutz,



Issues found so far, explanation in the previous postings.



[1] Repeating (pop) delivers 'not enough memory in function'

[2] Quoted text and the 2048 limit -> NO BUG

[3] The missing '-w' option when running 'newlisp -h'

[4] Segv in daemon mode

[5] (seek) returns any position

[6] (file-info) identifies symlinks but does not show correct size

[7] (file-info) hangs on PIPE files

[8] (sequence) does not show '0.0' in float sequences counting downwards





That's it for tonight, I am looking forward to see your replies :-)



Goodnight

Peter

[newdep]

LITTLE BUG# no port displayed



As an addon to the http server modes here is another one ->



starting newlisp with -d -c



$ newlisp -d -c

newLISP v.9018 listening on port 0





netstat will show you that newlisp started on a random port, this is nice that it does this

but the port number above is "0" instead of the random number chosen by newlisp.



On the otherhand the -d -c is not a corect syntax and should output an error.





Norman