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

Lutz · Post by **Lutz** » Fri Jan 26, 2007 2:13 pm

The list of Shame :-(

[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)

Actions and Comments :-)

[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:

lseek can set the file position past the current end of the file. This does not by itself make the file longer; lseek never changes the file. But subsequent output at that position will extend the file. Characters between the previous end of file and the new position are filled with zeros. Extending the file in this way can create a "hole": the blocks of zeros are not actually allocated on disk, so the file takes up less space than it appears to; it is then called a "sparse file".

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

pjot · Post by **pjot** » Sat Jan 27, 2007 11:07 pm

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.

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.

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.

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.

Code: Select all

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:

Code: Select all

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

Lutz · Post by **Lutz** » Sat Jan 27, 2007 11:27 pm

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

pjot · Post by **pjot** » Sun Jan 28, 2007 10:23 am

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':

Code: Select all

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:

Code: Select all

printf("Return: %s\n", 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

Lutz · Post by **Lutz** » Sun Jan 28, 2007 12:52 pm

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

newdep · Post by **newdep** » Sun Jan 28, 2007 8:11 pm

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.

pjot · Post by **pjot** » Mon Jan 29, 2007 4:25 pm

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

pjot · Post by **pjot** » Wed Feb 07, 2007 8:05 pm

Bug Hunting Season is closed!

Peter

newdep · Post by **newdep** » Thu Feb 08, 2007 7:10 am

Is it already a 15th ?...

I only did a 90 degrees on the code... It has to be put on 180 at least ;-)

pjot · Post by **pjot** » Thu Feb 08, 2007 7:47 am

According to the first post it stops at the 5th ;^)

...but if you still have bugs do not hesitate to let Lutz know!

Peter

cormullion · Post by **cormullion** » Thu Feb 08, 2007 5:46 pm

I've been trying to find bugs for weeks but they always turn out to be my fault... :-)