posix-getenv causes "Unhandled memory fault"

[Mark Chernev]

* (print (sb-ext:posix-getenv nil))
CORRUPTION WARNING in SBCL pid 12713(tid 140737354102528):
Memory fault at 0 (pc=0x7ffff7447a32, sp=0x7ffff517a6d8)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.

debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD
                                                            "initial thread" RUNNING
                                                            {1002BC7861}>:
  Unhandled memory fault at #x0.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-SYS:MEMORY-FAULT-ERROR)

---------------------------------------

> sbcl --version
SBCL 1.0.45

> uname -a
Linux foo 2.6.36-gentoo-r5 #1 PREEMPT Fri Dec 24 20:17:13 EST 2010 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

* (print *features*)

(:CL-PPCRE :QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ANSI-CL
 :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE
 :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86-64 :UNIX :ELF :LINUX
 :SB-THREAD :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD
 :C-STACK-IS-CONTROL-STACK :LINKAGE-TABLE :COMPARE-AND-SWAP-VOPS
 :UNWIND-TO-FRAME-AND-CALL-VOP :RAW-INSTANCE-INIT-VOPS
 :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS
 :CYCLE-COUNTER :COMPLEX-FLOAT-VOPS :FLOAT-EQL-VOPS :INLINE-CONSTANTS
 :MEMORY-BARRIER-VOPS :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR
 :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :OS-PROVIDES-GETPROTOBY-R
 :OS-PROVIDES-POLL)
(:CL-PPCRE :QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ANSI-CL
 :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE
 :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86-64 :UNIX :ELF :LINUX
 :SB-THREAD :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD
 :C-STACK-IS-CONTROL-STACK :LINKAGE-TABLE :COMPARE-AND-SWAP-VOPS
 :UNWIND-TO-FRAME-AND-CALL-VOP :RAW-INSTANCE-INIT-VOPS
 :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS
 :CYCLE-COUNTER :COMPLEX-FLOAT-VOPS :FLOAT-EQL-VOPS :INLINE-CONSTANTS
 :MEMORY-BARRIER-VOPS :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR
 :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :OS-PROVIDES-GETPROTOBY-R
 :OS-PROVIDES-POLL)

[William Halliburton (whalliburton)]

Fix attached.

[Stas Boukarev (stassats)]

That's only fixing a symptom. The problem is that NIL, when passed as a c-string, is translated into (int-sap 0), and into a reference to (int-sap 0).
I don't really see why c-string should accept NIL, so I attached two patches, one that handles NIL, and one that removes handling of NIL.

[Stas Boukarev (stassats)]

s/and into a reference to/and not into a reference to/

[William Halliburton (whalliburton)]

On Fri, Feb 18, 2011 at 10:17 AM, Stas Boukarev <email address hidden> wrote:
>
> I don't really see why c-string should accept NIL, so I attached two
> patches, one that handles NIL, and one that removes handling of NIL.
>

There may be valid uses of passing NULL into C functions CHAR * (which
c-string really is). My patch is localized to the problem at hand. The
getenv C function is causing a memory fault when passed in a NULL to its
CHAR * argument, which sounds like a bug in getenv, which I plug by
disallowing the passing of anything but strings. Maybe we need another c
type like c-string-no-null or such.

[Stas Boukarev (stassats)]

I don't see how passing NULL where a pointer to a char is expected is useful, NULL is a char, but it's not a pointer to one. And it's not limited to getenv, you can take any function which takes a c-string and you'll get a memory fault.
e.g.
(sb-posix:getpwnam nil) => Memory fault

[William Halliburton (whalliburton)]

I was referring to the C NULL macro which is the null pointer, and not the
NULL character.

You are correct that there are other functions that have this problem, which
is why I proposed some other way of indicating c-string-no-null. I am just
not convinced that there is no collateral damage from your patch on others
that allow for, and expect at times, a (CHAR *)0 to be passed in.

On Fri, Feb 18, 2011 at 11:06 AM, Stas Boukarev <email address hidden> wrote:

> I don't see how passing NULL where a pointer to a char is expected is
> useful, NULL is a char, but it's not a pointer to one. And it's not limited
> to getenv, you can take any function which takes a c-string and you'll get a
> memory fault.
> e.g.
> (sb-posix:getpwnam nil) => Memory fault
>
> --
> You received this bug notification because you are subscribed to SBCL.
> https://bugs.launchpad.net/bugs/721087
>
> Title:
> posix-getenv causes "Unhandled memory fault"
>

[Stas Boukarev (stassats)]

Now i agree that passing NULL is useful.

[Stas Boukarev (stassats)]

And null pointer passing isn't limited to c-strings, but it's common for all pointer types. The best way would be to have the ability to specify (and (not null) type).

[Nikodemus Siivola (nikodemus)]

I'm adding a :NOT-NULL option to C-STRING for now.

More general (and (not null) <alien-type>) or (not-null <alien-type>) left for later.

[Stas Boukarev (stassats)]

(sb-posix:readdir nil) memory faults too, and it's doesn't use a c-string.

[Nikodemus Siivola (nikodemus)]

Yeah, which is particularly nasty because

  (TYPEP NIL '(ALIEN (* T))) => NIL

but general alien pointer type translators accept NIL. This is probably due to a missing :LISP-REP method or something.

NOT-NULL needs to be really part of all pointer types.

[Nikodemus Siivola (nikodemus)]

In 1.0.46.19, but see also bug 727661.