<p dir="ltr">Dne 16.5.2014 18:36 "Glynn Clements" <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> napsal(a):<br>
><br>
><br>
> Radim Blazek wrote:<br>
><br>
> > There is a problem in G_fatal_error():<br>
> ><br>
> >     static int busy<br>
> >     if (busy)<br>
> >         exit(EXIT_FAILURE);<br>
> >     busy = 1;<br>
> ><br>
> > second G_fatal_error() call always exits.<br>
> ><br>
> > The busy check is there for the case when print error routine itself<br>
> > ends up with call to G_fatal_error()?<br>
><br>
> It's there to prevent infinite recursion, whether from the printing<br>
> code, a fatal error handler, or whatever.<br>
><br>
> > May be the busy variable made global and added a function to clear it?<br>
><br>
> That might be going a bit too far. OTOH, it can't be cleared prior to<br>
> calling the handler because it's intended to protect against the case<br>
> of a handler generating a fatal error.</p>
<p dir="ltr">I ment some G_fatal_error_recover() which would be called as last thing from QGIS error routine. </p>
<p dir="ltr">> One possibility would be to add explicit support for longjmp()ing out,<br>
> e.g. adding G_error_longjmp(jmp_buf env, int val) which would clear<br>
> the busy flag then perform the longjmp. That would avoid exposing the<br>
> internals more than is necessary.</p>
<p dir="ltr">Sounds good. </p>
<p dir="ltr">> Also, currently the global error handler (G_set_error_routine) is<br>
> called before the non-exclusive handlers (G_add_error_handler), so<br>
> those will never be called if the global handler lonjmp()s out. The<br>
> global error handler isn't limited to fatal errors, but is also used<br>
> for messages and warnings.</p>
<p dir="ltr">G_add_error_handler() is used by GRASS itself? </p>
<p dir="ltr">> Perhaps we need a dedicated fatal error handler for this purpose? It<br>
> would be called immediately prior to the final exit() call. It would<br>
> not be allowed to call GRASS functions or to return. The busy flag<br>
> could be cleared before calling it.</p>
<p dir="ltr">Whatever allows to "recover" from fatal error will help. I would prefer however not changing semantics too much so that GRASS 6, 7.0.0beta1 and 7.x.x may be easily supported by the same code with only few ifdefs. </p>

<p dir="ltr">Radim </p>
<p dir="ltr">><br>
> --<br>
> Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</p>