Greetings,
a few hours ago I have installed GNU Smalltalk from git, even posted my first blog post about it :-o I am having some troubles with gst-remote, however. Starting from scratch with a newly built image: stefan@g128 ~ $ gst -i -I gst.im "Global garbage collection... done" GNU Smalltalk ready st> ^D stefan@g128 ~ $ gst-remote -I gst.im --daemon stefan@g128 ~ $ gst-remote server started. stefan@g128 ~ $ gst-remote --eval '3+4' /usr/local/share/smalltalk/kernel/../scripts/Remote.st:276: Aborted (ip 44)SocketAddress class>>#extractAddressesAfterLookup: (ip 6)[] in SocketAddress class>>#allByName: (ip 4)<unwind> BlockClosure>>#ensure: (ip 48)[] in SocketAddress class>>#allByName: (ip 4)[] in SocketAddress class>>#at:cache: (ip 10)Dictionary>>#at:ifAbsent: (ip 18)SocketAddress class>>#at:cache: (ip 24)SocketAddress class>>#allByName: (ip 10)SocketAddress class>>#initLocalAddresses (ip 10)IPAddress class(SocketAddress class)>>#anyLocalAddress (ip 28)[] in UndefinedObject>>#executeStatements (ip 10)<unwind> BlockClosure>>#on:do: (ip 14)UndefinedObject>>#executeStatements (ip 0)<bottom> Aborted At this point, the server process is still running, but even just trying to "gst-remote --kill" it, shows now effect. So I guess that it's a problem in the client connecting to the server. BTW: what's the difference between --server and --daemon? Thanks, s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sat, 23 May 2009 01:51:04 +0200
Stefan Schmiedl <[hidden email]> wrote: > Greetings, > > a few hours ago I have installed GNU Smalltalk from git, > even posted my first blog post about it :-o > > I am having some troubles with gst-remote, however. Starting > from scratch with a newly built image: > > stefan@g128 ~ $ gst -i -I gst.im > "Global garbage collection... done" > GNU Smalltalk ready > > st> ^D > stefan@g128 ~ $ gst-remote -I gst.im --daemon > > stefan@g128 ~ $ gst-remote server started. > > > stefan@g128 ~ $ gst-remote --eval '3+4' > /usr/local/share/smalltalk/kernel/../scripts/Remote.st:276: Aborted > (ip 44)SocketAddress class>>#extractAddressesAfterLookup: > (ip 6)[] in SocketAddress class>>#allByName: > (ip 4)<unwind> BlockClosure>>#ensure: > (ip 48)[] in SocketAddress class>>#allByName: > (ip 4)[] in SocketAddress class>>#at:cache: > (ip 10)Dictionary>>#at:ifAbsent: > (ip 18)SocketAddress class>>#at:cache: > (ip 24)SocketAddress class>>#allByName: > (ip 10)SocketAddress class>>#initLocalAddresses > (ip 10)IPAddress class(SocketAddress class)>>#anyLocalAddress > (ip 28)[] in UndefinedObject>>#executeStatements > (ip 10)<unwind> BlockClosure>>#on:do: > (ip 14)UndefinedObject>>#executeStatements > (ip 0)<bottom> > Aborted > strace gst-remote --pid produces this: open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 4 fcntl(4, F_GETFD) = 0x1 (flags FD_CLOEXEC) fstat(4, {st_mode=S_IFREG|0644, st_size=1537, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f85614d6000 read(4, "# /etc/hosts: Local Host Database"..., 4096) = 1537 close(4) = 0 munmap(0x7f85614d6000, 4096) = 0 rt_sigprocmask(SIG_BLOCK, ~[QUIT ILL ABRT BUS SEGV RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[QUIT ILL ABRT BUS SEGV RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[QUIT ILL ABRT BUS SEGV RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- mprotect(0, 4096, PROT_READ|PROT_WRITE) = -1 ENOMEM (Cannot allocate memory) rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(7152, 7152, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- So somewhere it looks like gst is running out of memory. NB: Looking at the trace file made me wonder $ grep localtime gst-rem.log | wc -l 715 Why does gst-remote check /etc/localtime *that* often? Curious, s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Are you on amd64? If so, that's the same as
http://smalltalk.gnu.org/project/issue/264 > mprotect(0, 4096, PROT_READ|PROT_WRITE) = -1 ENOMEM (Cannot allocate memory) No, it's a NULL-pointer access. The mprotect fails, so GNU Smalltalk decides it's a real SIGSEGV rather than one that is handled by the generational garbage collection machinery. > NB: Looking at the trace file made me wonder > > $ grep localtime gst-rem.log | wc -l > 715 > > Why does gst-remote check /etc/localtime *that* often? tzset, probably. I should fix that. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Wednesday 27 May 2009 14:21:03 Paolo Bonzini wrote:
> Are you on amd64? If so, that's the same as > http://smalltalk.gnu.org/project/issue/264 > > > mprotect(0, 4096, PROT_READ|PROT_WRITE) = -1 ENOMEM (Cannot allocate > > memory) > > No, it's a NULL-pointer access. The mprotect fails, so GNU Smalltalk > decides it's a real SIGSEGV rather than one that is handled by the > generational garbage collection machinery. > > > NB: Looking at the trace file made me wonder > > > > $ grep localtime gst-rem.log | wc -l > > 715 > > > > Why does gst-remote check /etc/localtime *that* often? > > tzset, probably. I should fix that. > > Paolo > > > _______________________________________________ > help-smalltalk mailing list > [hidden email] > http://lists.gnu.org/mailman/listinfo/help-smalltalk Hi, it seems that the problems come with the value aiAddr in the CAddrInfoStruct class. I've tried to inspect an instance of CAddrInfoStruct and it failed when it has tried to print aiAddr. Cheers, Gwenael -- GtkLauncher for GNU Smalltalk : http://gtklauncher.bioskop.fr/ _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
> it seems that the problems come with the value aiAddr in the CAddrInfoStruct
> class. I've tried to inspect an instance of CAddrInfoStruct and it failed when > it has tried to print aiAddr. Seems easier than I was worried about! I'll look at it only next week unfortunately, but it's probably an int vs. long mismatch, or some other 64-bit cleanliness issue. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Paolo Bonzini-2
On Wed, 27 May 2009 14:21:03 +0200
Paolo Bonzini <[hidden email]> wrote: > Are you on amd64? If so, that's the same as > http://smalltalk.gnu.org/project/issue/264 Yes I am. Somehow I managed to overlook #264 while checking if this was already known. I'm duplicating my setup on one of my servers, let me know if you want to take a look there. s. > > > mprotect(0, 4096, PROT_READ|PROT_WRITE) = -1 ENOMEM (Cannot > > allocate memory) > > No, it's a NULL-pointer access. The mprotect fails, so GNU Smalltalk > decides it's a real SIGSEGV rather than one that is handled by the > generational garbage collection machinery. > > > NB: Looking at the trace file made me wonder > > > > $ grep localtime gst-rem.log | wc -l > > 715 > > > > Why does gst-remote check /etc/localtime *that* often? > > tzset, probably. I should fix that. > > Paolo > -- Stefan Schmiedl EDV-Beratung Schmiedl, Berghangstr. 5, D-93413 Cham im Büro: 09971 9966 989, am Handy: 0160 9981 6278 _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |