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:
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
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
>
At least this is inconsequent behaviour, as it does not happen with lists:
Quote
> (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
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"
Indeed a (dup " 00" 20) works but the 2049 boundary is never passed... strange...???
Quote
> (dup " 00" 20)
" 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
> (dup " 00" 2049)
[text][/text]
I seems Lutz will be busy ;-)
Its about auto conversion from "" to [text][/text].. Im not sure if its a bug..
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:
[text][/text]
> (length big)
3000
> (0 20 big)
" 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
> (2980 20 big)
" 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
>
I would say: not a bug.
Quote
I hope so :-), better to find them now than after the release. I throw in a T-shirt for the winner.
Lutz
Probably not to be qualified as a bug, but worth mentioning. In the "CHANGES-9.0.1-18.txt" we can read:
Quote
new -w <working> commandline switch
However, when we run 'newlisp -h' this option is not yet mentoned:
Quote
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
NewLisp in Linux segfaults with the following scenario.
First, start newLisp in daemon mode.
Quote
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.
Quote
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.
Quote
peter[~]$ newlisp -c -d 8080
Segmentation fault
peter[~]$
Peter
The (seek) function returns any position (Linux).
Create a file of a few bytes.
Quote
echo "blabla" > file.txt
Now open this file in newLisp and check the last position.
Quote
> (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:
Quote
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.
Quote
> (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:
Quote
On failure, seek returns nil.
But the only time a seek fails, is with numbers lower than -1.
Quote
> (seek 5 -100)
nil
> (seek 5 -2)
nil
Numbers larger than 0 all succeed and return a non-existing position.
Peter
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.
Quote
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.
Quote
> (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.
Quote
peter[~]$ mkfifo file.pipe
peter[~]$
Now run (file-info) on this file.
Quote
> (file-info "file.pipe")
That's right! In this situation, the (file-info) never returns.
Peter
Sequence does not show 0.0 (Linux)
The (sequence) command does not show a '0.0' in the following situation.
Quote
> (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:
Quote
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.
Quote
> (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
I though you already had a T-shirt? ;-)
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 ->
[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
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
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.
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
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
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 () ?
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
Yes your right... I was thinking empty but not empty enough ;-)
Quote
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
The (series) statement consumes all memory and CPU load
When we run this command:
Quote
(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
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) ->
[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.
Quote
'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:
Regards
Peter
Quote
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
[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)
[1] fixed in 9.0.19
string pops on empty strings will return ""
[2] not a bug
zero's in [text][/text] delimited do not get displayed, but the buffer is set correctly
[3] fixed in 9.0.19
missing options will show up in help
[4] cannot repeat on some platforms
on Mac OSX, FreeBSD and Solaris I cannot repeat this problem, on these platforms I get correctly a "(c)ontinue, (d)ebug, e(x)it, (r)eset" when hitting Ctrl-C. I wonder if the problem on Slackware is related to signal handling or an invalid socket handle? can you check using systrace or a similar tool.
[5] not a bug
This is the way its supposed to be, for creating sparse files in "update" mode: from the docs of GCC:
I will add something like above for 'seek' in the manual.
[6] not a bug
see changes notes for 'file-info' in 9.0.6 and discussion (will add more info in manual)
[7] fixed in 9.0.19
will return zero size for named pipes
[8] not a bug
hits rounding error at 16 digits of precision for double floats in binary/decimal conversion
[9] fixed in 9.0.19
starting server mode with no port number or 0 will fail
[10] fixed in 9.0.19
four counts < 1 'series' will return an empty list
Version 9.0.19 will be released on coming Monday
Lutz
Hi Lutz,
Thanks for your 9.0.19 release! And it sure is no list of shame. We all profit from improvements.
Also, in spite of my busy activities during this weekend, I could not resist looking at the SEGV problem. :-)
Also with 9.0.19 this problem occurs.
Resume: start newLisp in daemon mode.
Quote
peter[~]$ newlisp -c -d 8080
From another terminal, telnet to port 8080. Then press the standard '<CTRL> ]' and then 'q' to quit the telnet connection again.
Quote
peter[~]$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
^]
telnet> q
Connection closed.
peter[~]$
Go back to the first terminal and press <CTRL>+C to quit the newLisp daemon.
Quote
peter[~]$ newlisp -c -d 8080
Segmentation fault
peter[~]$
Now, with the wonderfull VALGRIND tool, I was able to trace back the cause of this problem. There is an invalid READ in your 'newlisp.c' at line 1965.
fprintf(IOchannel, "%s", buffer);
The problem is with the variable 'buffer', for which no memory is allocated. Indeed, the function 'varPrintf' does not allocate this variable at all! When I bruteforcefully change the code as follows:
1929 void varPrintf(UINT device, char * format, ...)
1930 {
1931 char * buffer;
1932 va_list argptr;
1933
1934 va_start(argptr,format);
1935
1936 /* new in 7201 , defined in nl-filesys.c if not in libc */
1937 buffer = (char*)malloc(sizeof(char)*1024); <------!!!!
1938 vasprintf(&buffer, format, argptr);
1939
...the problem is gone. As you can see, I allocate 1024 bytes. But I am not sure how large this allocation must be. However, if I change the code like this, the SEGV problem is gone.
I will verify your other fixes later and come back to you ASAP.
Cheers
Peter
The function vasprintf() is supposed to allocate the memory. Probably the implementation of vasprintf() on the Linux distribution is not to the spec of GCC.
Do the following in newlisp.h
#ifdef LINUX
#define vasprintf my_vasprintf
#define MY_VASPRINTF
#endif
The same is done already for OS2, MAC_OSX, SOLARIS and WINCC. Only the vasprintf() on FreeBSD seems to work as prescribed by the GCC docs. vasprintf() should allocate the memory for the buffer which then is freed by the user.
The above #ifdef should solve the problem using newLISP's own definition of vasprintf(), my_vasprintf() in nl-filesys.c.
Unfortunately the implementation of my_vasprintf() hits another frequent problem with the implementation in different compilers of vsnprintf(). Ther are further #ifdef in the my_vasprintf() for this, which at the moment distinguish between MINGW, TRU64 and anything else. LINUX should then fall into one of both groups.
Unfotunately I cannot repeat this problem to debug it myself but probably the #ifdef in newlisp.h alone will solve it, if not you might have to add:
#if defined(MINGW) || defined(TRU64) || defined(LINUX)
int the definition of myvasprintf() in the file nl-filesys.c
thanks for checking
Lutz
Good morning,
I have tried your macro workaround, but the same problem occurs. I even hardcoded 'vasprintf' to 'my_vasprintf' to make sure the function was entered and the result was the same (segfault).
The returnvalue from 'vasprintf' was equal to 'my_vasprintf'. It seems the memory for the buffer is allocated properly then.
Therefore I restored everything and checked valgrind again. The error occurs at line 1965 in 'newlisp.c':
1965 fprintf(IOchannel, "%s", buffer);
Instead of looking at buffer, I changed the variable IOchannel to 'stdout'. This also solved the segfault: I receive the default message on the console when pressing <CTRL>+<C>, presumably the correct output.
When I put the following code just before this line:
printf("Return: %sn", strerror(errno));
fflush(stdout);
...the warning 'bad filedescriptor' appears.
Looking through your code it seems you are using 'IOchannel' also for the daemon mode. Can it be that there is a problem with this filedescriptor? For with a <CTRL>+<C> you want to write a default message to the console, while at the same time this filedescriptor is in use for the newLisp daemon.
Regards
Peter
Tha bad filedescriptor in the Ctrl-C handler is definetly the reason. The descriptor gets invalid when the connection closes when telnet is quitted. The Ctrl-C handler always should write to stdout or stderr, I can change that.
Thanks for chasing this down
Lutz
Pjot..
What happens to newlisp if you open it with a net-connect ? and then press ctrl-c ?
(instead of opening it with a telnet)
Norman.
Hi Lutz,
Just tested the 9.0.19 release for the list below.
[1] Repeating (pop) delivers 'not enough memory in function' (Norman)
*Acknowledged - fixed.
[2] The missing '-w' option when running 'newlisp -h' (Peter)
*Acknowledged - fixed.
[3] Segv in daemon mode (Peter)
*Acknowledged - fixed. Norman: also with (net-connect) it works correctly.
[4] (seek) returns any position (Peter)
*Acknowledged - not a bug. Still I was VERY surprised the 'lseek' API works this way. Indeed it is described like you say in the manpages. From user-point-of-view this is very confusing but the addition in the manual is very clear. :-)
[5] (file-info) identifies symlinks but does not show correct size (Peter)
*Acknowledged - not a bug. The current change in the manual should be clear.
[6] (file-info) hangs on PIPE files (Peter)
*Acknowledged - fixed.
[7] (sequence) does not show '0.0' in float sequences counting downwards (Peter)
*You say this is not a bug, but it is highly confusing also. If the stepsize is '0.1' one would expect normal 'round' results...? But I understand the issue is intrinsic to float calculations...?
[8] newlisp -c -d always listens to port 0 instead of random number (Norman)
*Acknowledged - fixed.
[9] (series) with negative argument hangs PC (Peter)
*Acknowledged - fixed.
Thanks for the good work! You can close all these cases. ;-)
One week left for the bughunters among us...
Regards
Peter
Bug Hunting Season is closed!
Peter
Is it already a 15th ?...
I only did a 90 degrees on the code... It has to be put on 180 at least ;-)
According to the first post it stops at the 5th ;^)
...but if you still have bugs do not hesitate to let Lutz know!
Peter
I've been trying to find bugs for weeks but they always turn out to be my fault... :-)