Page 1 of 2
D(B)u(g)ck Hunting Season is opened!
Posted: Tue Jan 23, 2007 9:39 am
by 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.
- 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
BUG# POP
Posted: Tue Jan 23, 2007 4:24 pm
by newdep
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
>
Posted: Tue Jan 23, 2007 4:46 pm
by 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
BUG# quoted text and 2048 limit
Posted: Tue Jan 23, 2007 5:40 pm
by newdep
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"
Posted: Tue Jan 23, 2007 5:49 pm
by pjot
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 ;-)
Posted: Tue Jan 23, 2007 5:50 pm
by newdep
Its about auto conversion from "" to [text][/text].. Im not sure if its a bug..
Posted: Tue Jan 23, 2007 6:10 pm
by 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 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
Posted: Thu Jan 25, 2007 7:54 pm
by 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
Posted: Thu Jan 25, 2007 8:02 pm
by 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
Posted: Thu Jan 25, 2007 8:43 pm
by 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
Posted: Thu Jan 25, 2007 9:07 pm
by 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
Posted: Thu Jan 25, 2007 9:44 pm
by 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
Posted: Thu Jan 25, 2007 10:12 pm
by newdep
I though you already had a T-shirt? ;-)
Posted: Thu Jan 25, 2007 10:12 pm
by 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
LITTLE BUG# no port displayed
Posted: Thu Jan 25, 2007 10:21 pm
by 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
Posted: Thu Jan 25, 2007 10:27 pm
by newdep
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.
Posted: Thu Jan 25, 2007 10:32 pm
by pjot
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
Posted: Thu Jan 25, 2007 10:36 pm
by Lutz
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
is this a BUG?
Posted: Thu Jan 25, 2007 10:57 pm
by newdep
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 () ?
Posted: Thu Jan 25, 2007 11:09 pm
by Lutz
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
Posted: Thu Jan 25, 2007 11:11 pm
by newdep
Yes your right... I was thinking empty but not empty enough ;-)
Posted: Thu Jan 25, 2007 11:22 pm
by pjot
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
Posted: Fri Jan 26, 2007 9:46 am
by pjot
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
Posted: Fri Jan 26, 2007 10:00 am
by pjot
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
Posted: Fri Jan 26, 2007 12:55 pm
by Lutz
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