Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #25903
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: gForth and unix/pthread.fs |
| Date | 2013-09-21 20:44 +0200 |
| Organization | 1&1 Internet AG |
| Message-ID | <l1kpe9$fj6$1@online.de> (permalink) |
| References | (6 earlier) <l1hvcu$15u$1@online.de> <l1hvqe$1ti$1@online.de> <-ZGdnbpfIelX86DPnZ2dnUVZ_gidnZ2d@supernews.com> <l1k8ge$q7h$1@online.de> <ut6dnep6TsW8V6DPnZ2dnUVZ_jednZ2d@supernews.com> |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> The whole exception stuff in malloc() is impossible to use >> reasonable. If something goes wrong in malloc() or free(), the >> default (thread-safe) behavior is to print a C backtrace and a >> memory map and terminate the program. For a VM, this is inadequate, >> because the C backtrace is meaningless, and terminating the program >> is a bad idea, too. We have our own exception handling. > > The trouble with memory rashing bugs is that, in general, it's > extremely hard to recover from them in any reasonable way. So, in > many cases terminating the programs makes very good sense. This assumption is pretty wrong in Forth. Well, I certainly can't continue to run the program which uses malloc() and then has a buffer overflow. But: I can certainly keep the normal Forth system running, as this works pretty well without using malloc (unless you enter too long lines or so). That allows to examine the corrupted memory, and possibly determine what went wrong. bigForth has its own memory management system, and it adds enough stuff around the memory blocks to do sanity checking. There's a background task which regularly sweeps the memory blocks, does compacting of movable blocks and also reports corruped blocks; it of course stops when it finds such a block. This was very helpful to eradicate problems. I'll now check if setting mallopt(M_CHECK_ACTION, 1) is a better way to avoid program termination. It will not throw an exception, it will only print that there is a problem, and where it is. This is of *much* more dubious quality than throwing an exception, because you really can't let a program continue to run in normal mode after it had corrupted its memory. >> And first of all, I would expect that a non-thread-safe function for >> otherwise thread-safe stuff (malloc is very explicitely stated to be >> thread- safe) would have a big warning label in the manpage. > > So would I. I think that's the most annoying part. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
gForth and unix/pthread.fs voidvolker@gmail.com - 2013-09-16 00:43 -0700
Re: gForth and unix/pthread.fs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-16 09:05 +0000
Re: gForth and unix/pthread.fs voidvolker@gmail.com - 2013-09-16 05:43 -0700
Re: gForth and unix/pthread.fs VoidVolker <voidvolker@gmail.com> - 2013-09-19 10:14 -0700
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-20 01:26 +0200
Re: gForth and unix/pthread.fs VoidVolker <voidvolker@gmail.com> - 2013-09-19 19:17 -0700
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-20 16:20 +0200
Re: gForth and unix/pthread.fs VoidVolker <voidvolker@gmail.com> - 2013-09-20 08:43 -0700
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-20 19:07 +0200
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-20 19:14 +0200
Re: gForth and unix/pthread.fs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-21 05:02 -0500
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-21 15:55 +0200
Re: gForth and unix/pthread.fs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-21 11:32 -0500
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-21 20:44 +0200
Re: gForth and unix/pthread.fs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-22 05:03 -0500
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-22 21:18 +0200
Re: gForth and unix/pthread.fs VoidVolker <voidvolker@gmail.com> - 2013-09-21 11:41 -0700
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-21 21:18 +0200
Re: gForth and unix/pthread.fs VoidVolker <voidvolker@gmail.com> - 2013-09-21 13:55 -0700
Re: gForth and unix/pthread.fs Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-21 23:40 +0200
Re: gForth and unix/pthread.fs albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-09-21 12:59 +0000
csiph-web