gst-remote in git HEAD

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

gst-remote in git HEAD

Stefan Schmiedl
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
Reply | Threaded
Open this post in threaded view
|

Re: gst-remote in git HEAD

Stefan Schmiedl
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
Reply | Threaded
Open this post in threaded view
|

Re: gst-remote in git HEAD

Paolo Bonzini-2
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
Reply | Threaded
Open this post in threaded view
|

Re: gst-remote in git HEAD

MrGwen
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
Reply | Threaded
Open this post in threaded view
|

Re: gst-remote in git HEAD

Paolo Bonzini-2
> 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
Reply | Threaded
Open this post in threaded view
|

Re: gst-remote in git HEAD

Stefan Schmiedl
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