On 18 February 2015 at 13:38, Timo Sintonen via D.gnu <d.gnu@puremagic.com> wrote: > On Wednesday, 18 February 2015 at 13:07:12 UTC, Iain Buclaw wrote: >> >> On 18 February 2015 at 12:34, Timo Sintonen via D.gnu >> <d.gnu@puremagic.com> wrote: >>> >>> On Wednesday, 18 February 2015 at 12:12:04 UTC, Iain Buclaw wrote: >>> >>>> >>>> You can't throw without a GC allocation currently. I'm open to >>>> suggestions and patches welcome. >>>> >>>> See here: >>>> >>>> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/deh.d#L152 >>>> >>>> >>>> Iain. >>> >>> >>> >>> I was just goimg to ask about the state of this. >>> I have understood that this struct carries all the necessary info trough >>> unwinding and it is not freed until gc frees it. >>> Where is the last place this struct is used. Is it in druntime side or in >>> libgcc side? >> >> >> The last place it is used is on the libgcc side, or at least the >> generic exception header that our language-dependent header holds. >> >> It may be a better solution to have a static TLS pointer that gets >> new'd upon thread start. Perhaps even make it a pre-allocated array >> so we might be able to get chained exceptions working in GDC runtime. >> >>> Could it be possible to allocate this with malloc and free after >>> unwinding? >>> I have understood that this struct is not available any more in catch >>> block. >>> Do we need many copies of this. Could it be possible to have a static >>> one? >> >> >> See __gdc_exception_cleanup just above _d_throw. We use destroy(p) in >> the cleanup. It could work to swap 'destroy' with 'free', and 'new' >> with 'calloc'. But that still doesn't help if we are throwing an >> OutOfMemory exception. It will still fail hard, rather than bail with >> a nice backtrace. >> >> Iain > > > Out Of Memory is a special case and usually a fatal case. There was some > discussions lately about this but I did not follow it. > If OutOfMemory is not working anyway then we do not loose anything? We may > get the other exceptions to work. So why not make this until we find out > some better solution? >
Regardless, "Out of Memory" is a more informative message than "Segmentation Fault". Especially so if you are the one trying to debug the program. And find the 'trigger'. :-) Iain
