[gambit-list] What is the best strategy to ensure that non-FFI code can never cause sigsegv:s / bus errors?

Mikael More mikael.more at gmail.com
Thu Aug 14 09:48:45 EDT 2008


Hi!

A month ago, I sent the email below, indicating that there are bugs in
Gambit that lead to program crashes, such as SIGSEGV:s.

I wish to update you on our current understanding, which is that there are
no bugs in Gambit that lead to crashes, with one exception, which is upon
invocation of (lambda (#!key ... #!rest ..) .. ). This is a bug that Marc
mentioned on this list earlier this year. Until it is fixed, using Gambit's
built-in print function is not recommended.

Uses that can make Gambit crash is executing code that does not completely
perform typechecks, with (declare (not safe)), and feed it with unintended
input data. (For instance, in a way that makes it try to access the contents
of, or execute, #!unbound or #!void). It should be noted that the
Gambit-internal functions, having names starting with ##, do not perform
typechecks. The Termite version that was online between ~april and until the
updated release the 14:th of July did something like this.

Also, a source of program crashes may originate from an unawareness among
developers as regards the C FFI, that the arguments passed into a c-lambda
may change contents, if the C-lambda in turn accesses Scheme functions.
Thus, backup ___argXX you want left to the stack before invoking the Scheme
world from a C function.

I admit that the last two paragraphs may not describe the addressed
phenomena completely, the point I wanted to make with this email was just
that we have not seen any bugs in Gambit causing software crashes, with one
peripheral exception, as described above.

Thanks

Mikael

-

2008/7/9

> Hi!
>
> We're having limited problems with our Gambit software throwing sigsegvs /
> bus errors, on x86 debian and on mac os x.
>
> The instances we see that we have had sigsegvs / bus errors in are:
>  - when using #!unbound or #!void values in code compiled with (declare
> (not safe))
>  - when not catching exceptions (like in the example below)
>  - immediately following C calls from Scheme, where the C code makes
> callbacks back into Scheme, though these errors may be due to us using
> broken FFI code.
>
> What are the best strategies to ensure that non-FFI code can never cause
> sigsegv:s / bus errors?
>
> ( I suppose for starters, it is not to override the default (declare
> (safe)) declaration. What more? )
>
> Thanks
> Mikael
>
>  -
>
> The following example produces sigsegv  undepending on if compiled with gcc
> or  g++. Executing (termite#spawn (lambda () (raise "hi")))  works as
> expected, it does not throw any sigsegv.
>
> debian:~/main$ gdb gsc
> GNU gdb 6.4.90-debian
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i486-linux-gnu"...Using host libthread_db
> library "/lib/tls/i686/cmov/libthread_db.so.1".
>
> (gdb) run
> Starting program: /usr/bin/gsc
> Failed to read a valid object file image from memory.
> Gambit v4.2.8
>
> > (load "~~/lib/termite/termite")
> "/usr/local/Gambit-C/v4.2.8/lib/termite/termite.o1"
> > (termite#node-init (termite#make-node "127.0.0.1" 3000))
> ok
> >  (termite#spawn (lambda () (raise "hi")))
> #<thread #2>
> >
> Program received signal SIGSEGV, Segmentation fault.
> 0x08220202 in ___H__20___kernel ()
> (gdb) bt
> #0  0x08220202 in ___H__20___kernel ()
> #1  0x00000000 in ?? ()
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20080814/6f7ec4fd/attachment.htm>


More information about the Gambit-list mailing list