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

pjot · Post by **pjot** » Tue Jan 23, 2007 9:39 am

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.

The Bug Hunting Season starts as of today and will end at february 5.

Bugs in the documentation will not be rewarded.

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

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 · Post by **newdep** » Tue Jan 23, 2007 4:24 pm

BUG# POP

9.0.18 release ->

The integer is passing beyond end of string..and even beyond "\000"
(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)
"\000"
> (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 · Post by **pjot** » Tue Jan 23, 2007 4:46 pm

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 · Post by **newdep** » Tue Jan 23, 2007 5:40 pm

BUG# quoted text and 2048 limit

newlisp-9.0.18 ->

"\000" is not automaticly converted to [text] [/text] when it passed the
boundery of 2048, whereas other strings are..

This works ->

(dup "bug" 2049)
(dup {\000} 2049)

and this not ->

(dup "\000" 2049)
(returns -> [text][/text])

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

pjot · Post by **pjot** » Tue Jan 23, 2007 5:49 pm

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

> (dup "\000" 20)
"\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
> (dup "\000" 2049)
[text][/text]

I seems Lutz will be busy ;-)

newdep · Post by **newdep** » Tue Jan 23, 2007 5:50 pm

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

Lutz · Post by **Lutz** » Tue Jan 23, 2007 6:10 pm

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 all

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

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 · Post by **pjot** » Thu Jan 25, 2007 7:54 pm

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 · Post by **pjot** » Thu Jan 25, 2007 8:02 pm

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 · Post by **pjot** » Thu Jan 25, 2007 8:43 pm

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 · Post by **pjot** » Thu Jan 25, 2007 9:07 pm

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 · Post by **pjot** » Thu Jan 25, 2007 9:44 pm

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 · Post by **newdep** » Thu Jan 25, 2007 10:12 pm

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

pjot · Post by **pjot** » Thu Jan 25, 2007 10:12 pm

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 · Post by **newdep** » Thu Jan 25, 2007 10:21 pm

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

newdep · Post by **newdep** » Thu Jan 25, 2007 10:27 pm

A small remark for pjot:

The linux Segmentation fault is an old bug that lays in slackware I can remember
mentioning this already back in the 8.xx release. It only happens on slackware it seems.

The Symlink is correct, you want to see the file size and not the symlink size,
althought I find no use in the size of the symlink, i want to see the file size.

pjot · Post by **pjot** » Thu Jan 25, 2007 10:32 pm

If you want to see the filesize, then query the file. The (file-info) mentions we're looking at a symlink; I find it confusing that I see a symlink with the size of the original file.

Also, symlinks can have different sizes themselves.

For the Segv, I am using Zenwalk 4.2, which is a Slackware spinoff, but still different from Slack 8. It is strange the issue appears in this distribution as well. Anyway, if Lutz cannot reproduce the problem, it will not count as a bug. :-)

Peter

Lutz · Post by **Lutz** » Thu Jan 25, 2007 10:36 pm

Thanks Peter and Norman for the bug hunting efforts!

I will report on all of these tomorrow except for [6]:

'file-info' since version 9.0.6 uses lstat(), previously stat(), to report on files. This means that on symbolic links file sizes are reported for the linked file not for the link itself, but the mode field shows that the path-name was for a link. The change was made because it seemed more practible to report file-zise on the linked file rthan on the link.

Lutz

newdep · Post by **newdep** » Thu Jan 25, 2007 10:57 pm

is this a BUG?

Lutz, I find this odd, but perhpas you can clear me up ->

(list '())
> (())

(map list '())
> ()

(map list '(0))
>((0))

(map list (dup '() 1))
> ((()))

Why does (map list '()) not return (()) but () ?

Lutz · Post by **Lutz** » Thu Jan 25, 2007 11:09 pm

This is not a bug.

'map' applies a function to all members of the list and returns the list of results. Because the arguments list was empty nothing was done and the result list is empty.

Lutz

newdep · Post by **newdep** » Thu Jan 25, 2007 11:11 pm

Yes your right... I was thinking empty but not empty enough ;-)

pjot · Post by **pjot** » Thu Jan 25, 2007 11:22 pm

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

Yes I do!! But as organizer of the Bug Hunting Season I am excluded from any price. :-)

Peter

pjot · Post by **pjot** » Fri Jan 26, 2007 9:46 am

The (series) statement consumes all memory and CPU load

When we run this command:

(series 1 5 -1)

...my PC hangs. I almost had to reboot, but with some effort I could kill the newLisp process manually. The error is caused probably because the '-1' is considered to the max 64bit number?

Peter

pjot · Post by **pjot** » Fri Jan 26, 2007 10:00 am

New list with homework extended with bugs found, including submitter.

[1] Repeating (pop) delivers 'not enough memory in function' (Norman)
[2] Quoted text and the 2048 limit (Norman) -> NO BUG - will be left out in future buglists
[3] The missing '-w' option when running 'newlisp -h' (Peter)
[4] Segv in daemon mode (Peter)
[5] (seek) returns any position (Peter)
[6] (file-info) identifies symlinks but does not show correct size (Peter)
[7] (file-info) hangs on PIPE files (Peter)
[8] (sequence) does not show '0.0' in float sequences counting downwards (Peter)
[9] newlisp -c -d always listens to port 0 instead of random number (Norman)
[10] (series) with negative argument hangs PC (Peter)

Now your remark on the (file-info) of symlinks.

'file-info' since version 9.0.6 uses lstat(), previously stat(), to report on files. This means that on symbolic links file sizes are reported for the linked file not for the link itself, but the mode field shows that the path-name was for a link. The change was made because it seemed more practible to report file-zise on the linked file rthan on the link.

Well, from Unix point of view I tend to not agree, because of the following reasons:
1) for Unix, symlinks are real files, and they can have different filesizes themselves
2) the newLisp programmer might be interested in these sizes if he wants to hack the filesystem, for example
3) isn't it kind of contradictory: the (file-info) reports a symlink, but shows the size of the original file?

I understand it is easy to have a common implementation for all OS's (Win32 will not have this problem), so for sake of portability you might want to leave it as it is. But probably there should be a remark about it in the manual, if you decide to keep it this way...?

To all forum readers: you are encouraged to find bugs! You can win a genuine newLisp T-shirt!

Regards
Peter

Lutz · Post by **Lutz** » Fri Jan 26, 2007 12:55 pm

isn't it kind of contradictory: the (file-info) reports a symlink, but shows the size of the original file?

From a practical proint of view, one is probably more interested in the size of the file linked to than of the size of the link. The change in 9.0.6 was made in response to a user who primarily is not a programmer. This kind of user tends to see programming more from an applicative kind of perspective, which is a good thing according to newLISP's philosophy.

I am almost done dealing with your list and will post fixes and comments later today.

Lutz