Segmentation Fault running NewLisp "Daemon mode"

[Lutz]

This is hard to fix for me as I cannot reproduce it on my Linux installation, can you find out where it exits with a trace?



The only exit I see in the program ogic is when the accept() call falls through and leaves the 'connection' variable with a NULL, but then you would get a message: "newLISP server setup on port xxx failed" and you don't seem to get this. So I think is bombing out somewhere?



Lutz

[Lutz]

thanks for testing Eddie, on my side I am running Kernel 2.4.22 on Mandrake 9.2. Norman, what Linux are you running?



Lutz



ps: you mentioned it already Norman: slackware 2.4

[newdep]

Hello Lutz,



Running linux 2.4.20



here is my trace, this time it pops-out at "semget" or the exit(1) = ? see below...





accept(3, {sin_family=AF_INET, sin_port=htons(35464), sin_addr=inet_addr("127.0.0.1")}}, [16]) = 1

getpeername(1, {sin_family=AF_INET, sin_port=htons(35464), sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0

time(NULL)                              = 1090390017

open("/etc/localtime", O_RDONLY)        = 4

fstat64(4, {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0

old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000

read(4, "TZifrr"..., 4096) = 1074

close(4)                                = 0

munmap(0x40015000, 4096)                = 0

fcntl64(1, F_GETFL)                     = 0x2 (flags O_RDWR)

fstat64(1, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0

old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000

_llseek(1, 0, 0xbffff4c0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)

munmap(0x40015000, 4096)                = 0

write(1, "newLISP v8.0.12 Copyright (c) 20"..., 70) = 70

ioctl(1, SNDCTL_TMR_TIMEBASE, 0xbffff650) = -1 EINVAL (Invalid argument)

write(1, "n> ", 3)                     = 3

read(1, "r", 1)                        = 1

read(1, "n", 1)                        = 1

write(1, "n> ", 3)                     = 3

read(1, "(", 1)                         = 1

read(1, "e", 1)                         = 1

read(1, "x", 1)                         = 1

read(1, "i", 1)                         = 1

read(1, "t", 1)                         = 1

read(1, ")", 1)                         = 1

read(1, "r", 1)                        = 1

read(1, "n", 1)                        = 1

close(1)                                = 0

close(1)                                = -1 EBADF (Bad file descriptor)

accept(3,

bash-2.05b$

bash-2.05b$ fg

strace newlisp -d 5001

0x8068bf8, [4294967295])      = -1 EINVAL (Invalid argument)

getpeername(-1, 0xbffff630, [16])       = -1 EBADF (Bad file descriptor)

time(NULL)                              = 1090390074

semget(1, 0, 0x5|04)                    = -1 ENOSYS (Function not implemented)

_exit(1)                                = ?

[Lutz]

Thanks Norman, when restarting the server the accept() call seems to fail on slackware, perhaps because the listen socket is invalid.



In http://newlisp.org/downloads/development/Norman/">http://newlisp.org/downloads/development/Norman/



you find a version which tries to reopen the port for listening.



Lutz



ps: perhaps Steve knows how to use CreateProcess in Win32 ?

[newdep]

Hi Lutz,



just tested the 8.0.12Norman release but unfortunatly no change.. here

is the trace...hope it gives a little insight...



second connect is refuced and the daemon exits...strange it is...





accept(3, {sin_family=AF_INET, sin_port=htons(32819), sin_addr=inet_addr("127.0.0.1")}}, [16]) = 1

getpeername(1, {sin_family=AF_INET, sin_port=htons(32819), sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0

time(NULL)                              = 1090447188

open("/etc/localtime", O_RDONLY)        = 4

fstat64(4, {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0

old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000

read(4, "TZifrr"..., 4096) = 1074

close(4)                                = 0

munmap(0x40015000, 4096)                = 0

fcntl64(1, F_GETFL)                     = 0x2 (flags O_RDWR)

fstat64(1, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0

old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000

_llseek(1, 0, 0xbffff4a0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)

munmap(0x40015000, 4096)                = 0

write(1, "newLISP v8.0.12 Copyright (c) 20"..., 70) = 70

ioctl(1, SNDCTL_TMR_TIMEBASE, 0xbffff630) = -1 EINVAL (Invalid argument)

write(1, "n> ", 3)                     = 3

read(1, "(", 1)                         = 1

read(1, "e", 1)                         = 1

read(1, "x", 1)                         = 1

read(1, "i", 1)                         = 1

read(1, "t", 1)                         = 1

read(1, ")", 1)                         = 1

read(1, "r", 1)                        = 1

read(1, "n", 1)                        = 1

close(1)                                = 0

accept(3, 0x8068d38, [4294967295])      = -1 EINVAL (Invalid argument)

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 1

bind(1, {sin_family=AF_INET, sin_port=htons(5001), sin_addr=inet_addr("0.0.0.0")}}, 16) = -1 EADDRINUSE (Address already in use)

close(1)                                = 0

semget(1, 0, 0x5|04)                    = -1 ENOSYS (Function not implemented)

_exit(1)                                = ?

[1]+  Exit 1                  newlisp -d 5000

bash-2.05b$

[Lutz]

Strange, it will not let me do accept() on the old listen socket, but also not let me bind the new one -> "Address already in use".



I will keep on trying ...



Lutz

[Lutz]

The version 8.0.14 in http://newlisp.org/downloads/development/">http://newlisp.org/downloads/development/ fixes this. tested on MinGW, Debian, ReadHat, Mandrake, FreeBSD, OpenBSD, Mac OSX, AMD64 and Solaris. I am confident with Norman testing it, we can add Slackware to the list.



The bug wasn't very sophisticated, just uninitialized data structures (shame on me ;-) ). On the Sourceforge compiler farm I could find an OS which also showed the problem and then was able to fix it.



Lutz

[newdep]

Hello Lutz,



Thanks for the fix en enhancements,

its running now under slackware ;-) Great...





Regards, Norman.