Re: [OctDev] [PATCH] CVS-octave-forge and GCC3.2

[Paul K. <pki...@ja...>]

I've sprinkled very ugly OCTAVE_QUIT and BEGIN/END_INTERRUPT_IN_FOREIGN_CODE
macros throughout the sparse functions.

sp_test continues to work, even after Ctrl-C.  But if you have top running,
you can see that Ctrl-C leads to big memory leaks.

There is a new debug_on_interrupt flag.  I have confirmed that it will
drop you into a debug prompt on Ctrl-C, but I haven't checked that it
is in a valid state when you do.  In particular, I don't know if the
current line has been run to completion, or if dbg_cont will cause it
to be executed again.  The few simple tests I did (sp_test followed
by Ctrl-C followed by dbg_cont) seem to work.

I don't know how to generate internal sparse errors, so I don't know that
I have SuperLU compiled correctly to throw fatal errors through C code.
I'm hoping that these errors will all be memory errors so that throwing a 
bad_alloc exception is appropriate.

Elsewhere sparse is using SP_FATAL_ERROR rather than laboriously 
returning the error up the stack.  E.g., sparse(1,1,[1,2])
Since it is SP_FATAL_ERROR which is throwing the bad_alloc exception,
this is erroneously labeled a "memory exhausted" error.  I'm willing
to live with that for the moment, but I'm happy to accept patches to
fix it properly.

I don't want to put to much energy into it until I know which sparse
package John is going to use in Octave.  I've seen reports on the web that
umfpack and mumps are both faster than superlu, so maybe we will change
packages.  I know in particular that umfpack does propogates error codes
rather than punting to a fatal error handler, which will remove at least
some of the problems in the code.

I can now build octave-forge against 2.1.40 without error, at least
the subset that I'm installing.  Please test and report any errors.

Paul Kienzle
pki...@us...

On Tue, Nov 26, 2002 at 09:33:12PM +0000, Nix wrote:
> On Mon, 25 Nov 2002, Paul Kienzle yowled:
> > On Mon, Nov 25, 2002 at 08:35:11PM +0000, Nix wrote:
> >> ... oh, damn and blast, SuperLU is C. I didn't notice and thought it was
> >> C++.
> > 
> > Maybe all is not lost.  I forgot that we are recompiling superlu ourselves.
> > When I tested this a couple of years ago, I found that I could do something
> > like:
> 
> [throw through C]
> > This seems to still work.  I don't know what to throw though.
> 
> Yes, this will always work; we'd be in some trouble being ISO C++
> compliant otherwise --- the Standard requires throws through
> std::qsort() and std::bsearch() to work, in s17.3.4.8.2 --- and POSIX
> has a good few callback-style routines, which it would be nice to allow
> exceptions to be thrown through.
> 
> I guess we could have done it by reimplementing qsort() and bsearch() in
> libstdc++-v3, but that would have been ugly.
> 
> (Obviously, exception throws through non-GCC-compiled C code won't work,
> except on the IA64, which has hardware support for exceptions. :) )
> 
> 
> One problem is that this is a rather GCC-specific solution :( I'm sure
> there are compilers out there that *don't* support throwing through C
> code.
> 
> But luckily we don't need to do this at all. (See below.)
> 
> > 
> > 	octave_throw_interrupt_exception() ?
> > 	octave_throw_bad_alloc() ?
> 
> Neither.
> 
> > If this works, I can push out a new octave-forge very soon,
> > but Ctrl-C will not be responsive within superLU.
> > 
> > For Ctrl-C we need to put OCTAVE_QUIT in all the inner loops of *.{cc,h}
> 
> No need :)
> 
> > and wrap calls to superLU with BEGIN/END_INTERRUPT_WITH_EXCEPTIONS.
> > At least I think that's what we are supposed to do.
> 
> No need for any of that; the _IMMEDIATELY_ variants of those macros set
> up a setjmp() / throw layer. The Octave signal handlers in
> src/sighandlers.cc spot that we're inside an _IMMEDIATELY_ wrapper
> (because `octave_interrupt_immediately' is nonzero) and (sig)longjmp
> there for us.
> 
> > It's not clear how we can clean up a superLU malloc which was interrupted
> > during initialization.  I believe that's why garbage collection was
> > invented.
> 
> You can't clean that up, but then we've *never* been able to clean that
> up. At least this way destructors for C++ objects get called :)
> 
> (Hell, there's a worse case than that: the SIGINT is asynchronous, so it
> can arrive in the middle of a malloc(). If it does that, we're
> completely screwed and the heap is fubared. But this, too, has always
> been the case, and there don't seem to be many bug reports that can be
> traced to screwed heaps. So I guess this is rare enough to ignore.)
> 
> Leaving the bit below because it's still relevant:
> 
> >> OK, C that counts as foreign code, so calls into SuperLU will require
> >> BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
> >> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE wrapped around them. That
> >> should let the code flow when interrupted by SIGINT within SuperLU go
> >> 
> >> SIGINT -> signal handler in octave's src/sighandlers.cc ->
> >> octave_jump_to_enclosing_context() -> longjmp() to the
> >> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE -> Octave's toplev.cc.
> >> 
> >> > The macros to do this are in quit.h, but I don't know the exact magic.
> >> 
> >> I think I've decrypted it.
> >> 
> >> > Let me know if you are going to persue this, because it is top of my list
> >> 
> >> It's top of mine too. Patch in an hour or so (this box is running rather
> >> slowly right now, alas, and it would be inurbane for me to antinice
> >> everyone else into oblivion).
> 
> I got stalled by wondering how best to wrap *all* calls into SuperLU. I
> guess that a thin C++ wrapper around SuperLU is indicated, each of which
> does careful BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE /
> END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE calls.
> 
> --- oh, this is only needed in computationally expensive stuff. In cheap
> calls we can just ignore it and leave the calls undecorated, because the
> user won't interrupt in there and won't notice the delay even if he
> does. (Decorating such calls is probably a bad idea, actually, because
> the setup and teardown for the _INTERRUPT_IMMEDIATELY_ stuff isn't
> free.)
> 
> So probably that's just a few potentially-expensive SuperLU calls we
> need to decorate.
> 
> Any idea which they are? I haven't much of a clue :)
> 
> -- 
> `I keep hearing about SF writers dying, but I never hear about SF
>  writers being born.  So I guess eventually there'll be none left.'
>                                     -- Keith F. Lynch
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev