Re: [Gcl-devel] strings copied across heap/local data boundaries

[Michael Koehne]

Moin Mike Thomas,

> So I stuck BEGIN/END_NO_INTERRUPT into open_stream and lo and behold the
> formerly repeatable error was replaced by another repeatable error of
> similar nature much later in the Maxima build - at the point where all the
> object modules are being loaded after compilation.


  *hm* this opens the next can of worms ;( signals&sockets - even Perl 5
  is broken here ! ....

  could you tell me, who is sending those signals ? Are those external
  signals like SIGPIPE, if some program open a pipe - or deceased
  background processes who are sending a SIGALRM ?

  patching a BEGIN_NO_INTERRUPT into those places a race condition
  did occur, might not help, as this kind of race condition could
  occure everywhere. It might be better to rewrite the signal handling
  to always delay them and excute them at a save place.  Then only the
  real race conditions (every system call) need signal protection.

  Such a general SIGNAL overhaul (/me think that signals are still
  coded like on good old UnixSysIII+BSD4.2/a.out days ;) might also
  integrate the multithreading patches from ECL, as being signal
  save in design is necessary for them.

> This particular bug has
> never manifested at that late stage before so I take this as a positive sign
> and an indication that we need to systematically track down similar
> unbracketed string/data copies across local/heap boundaries of which there
> appear to be several including, significantly, "o/pathname.d".

  *hm* could you point me to those places - and look, if my patch
  already touched them ?

Bye Michael
-- 
  mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM