What is the best strategy to ensure that non-FFI code can never cause sigsegv:s / bus errors?
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 ?? ()
Afficher les réponses par date
On Jul 9, 2008, at 10:15 AM, Mikael More wrote:
( I suppose for starters, it is not to override the default (declare (safe)) declaration. What more? )
As far as I know, that should be it. What I also find helpful is to use type-specific arithmetic operations (fx+, fx-, ... or fl+, fl-,...) when you expect the types of the arguments to be known; together with (declare (safe)), this will check your assumptions and tell you if you're wrong.
Brad
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 ?? ()
-
Bradley Lucier -
Mikael More