Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #25903

Re: gForth and unix/pthread.fs

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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