Greetings,
I saw a memory-fault error in a multithreaded web server
application running on 0.9.17.17 non-unicode[1] x86 running on Debian
GNU/Linux 3.1, kernel 2.6.8, in the following context:
...
15: (SIGNAL #<SB-KERNEL::MEMORY-FAULT-ERROR {B081289}>)
16: (ERROR SB-KERNEL::MEMORY-FAULT-ERROR)
17: (SB-KERNEL::MEMORY-FAULT-ERROR)
18: ("foreign function: call_into_lisp")
19: ("foreign function: post_signal_tramp")
20: (SB-IMPL::READ-FROM-C-STRING/LATIN-1 #.(SB-SYS:INT-SAP #X656C6261) CHARACTER)
21: (SB-BSD-SOCKETS::MAKE-HOST-ENT #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X40199178 :TYPE (* (STRUCT SB-BSD-SOCKETS-INTERNAL::HOSTENT (SB-BSD-SOCKETS-INTERNAL::NAME #) (SB-BSD-SOCKETS-INTERNAL::ALIASES #) (TYPE #) (LENGTH #) (SB-BSD-SOCKETS-INTERNAL::ADDRESSES #) (SB-BSD-SOCKETS-INTERNAL::PADDING5 #)))>)
22: (ACL-COMPAT.SOCKET:LOOKUP-HOSTNAME "censored" :IGNORE-CACHE NIL)
...
Apparently read-from-c-string/latin-1 is called from code generated
by some alien magic to read c-string structure fields in
sb-bsd-sockets::make-host-ent.
Juho Snellman informed that the code that calls
read-from-c-string/latin-1 is in c-string-to-string these days but
it shouldn't be called for ISO 8859-1 on a non-Unicode build but
instead %naturalize-c-string should be used.
If that is correct, there seems to a bug somewhere.
Now, whether that is correct or not, there is this memory fault
error. I can't think of any other reason except that the string is
moved by GC while read-from-c-string/latin-1 is working on it. I
see that there is a comment above %naturalize-c-string that
suggests the problem is known but it shouldn't happen on x86. I
wonder if that comment needs to be rethought... There are some
worrisome comments also at the end of host-c-call.lisp in the
c-string :deport-gen alien type method definition.
[1] My customize-target-features.lisp contains
(lambda (list) (list* :sb-futex :sb-thread (remove :sb-unicode list)))
--
Hannu
|