[DGD] Segfault

[bart at wotf.org]

To expand a little on this:

In Gurbalib, you could create a function like this:

atomic int fun(int i) {
   catch {
      return 10 / i;
   } : {
      rethrow();
   }
}

The rethrow() afun this uses looks as follows:


#include <error_handling.h>

void rethrow(varargs string str) {
   string error;
   string *lines;

   if (error = caught_error(1)) {
      if (str) {
         lines = explode(error, "\n");
         lines[0] = str;
         error = implode(lines, "\n");
      }
      error(MAGIC_ERROR_RETHROWN + error);
   }
}

What this does is get the text representation of the caught error trace,
optionally replace the first line of it, prepend a magic string for the error
handler to recognize this is an encoded error string, and then cause a new
error with the constructed string as error message

The errorhandler scans errors for this magic string, uses the part after it as
an already text converted stack trace, logs it, and ignores the actual stack
trace (it points to the call to the atomic function, not to what happened
inside the atomic function)

There is a caught_error() afun on gurbalib which retrieves caught errors from
the TLS. The errorhandler is responsible for adding this information to the TLS.

Additionally, there is support for the add_atomic_message() and
get_atomic_message() afuns, which are functional clones of the same afuns in
Cloudlib. This can be used to achieve similar functionality.

Bart.

On Thu, 19 May 2016 20:03:35 +0200, bart wrote
> Wrap the code in your atomic function 
> in a catch statement and throw a new 
> error, and you will be able to pass 
> errors inside your atomic function to 
> the 'outside' using the error string 
> of the new error you throw by encoding 
> the original error and stack.
> 
> Cloudlib and gurbalib both have 
> mechanisms to do such things.
> 
> You will have to parse and decode 
> error strings for this to work, but it 
> allows logging the original error in 
> an atomic function to a file.
> 
> Catching the error handler and having 
> a last resort is pretty much 
> mandatory, especially when the error 
> handler becomes more complex.
> 
> There is one not so obvious thing to 
> keep in mind when writing to the 
> console, the actual output will pass 
> through functions using C style string 
> handling. LPC strings can contain nul 
> chars (byte value 0), which will work 
> as a string terminator in C. Hence 
> strings with such chars will be 
> truncated when printed to the condole.
> 
> Bart
> 
> On Thu, 19 May 2016 07:04:33 -0700, 
> Raymond Jennings wrote
> > Of note, this also helps when I get 
> a craw biter in atomic_error, which
> > helps when I can't use file based 
> logging.
> > 
> > On Thu, May 19, 2016 at 7:00 AM, 
> Raymond Jennings 
> > <shentino at gmail.com> wrote:
> > 
> > > Ahh...so it was an infinite 
> recursion after all.
> > >
> > > First of all...never mind the bug 
> report.
> > >
> > > Second of all...I have a trick to 
> catch problems like that.  Wrap your
> > > whole error handler in a catch, 
> and in the handler section just spit 
> out a
> > > simple message to the console.
> > >
> > > If you can steal the stack trace 
> reporter from the kernel library's 
> driver
> > > object you can also spit that out 
> to console too.
> > >
> > > On Thu, May 19, 2016 at 6:57 AM, 
> Blain <blain20 at gmail.com> wrote:
> > >
> > >> Yep.  My error service was 
> bugging while compiling the trace 
> text.  When
> > >> fixed, I found that the static 
> function being called was causing an 
> error
> > >> because I'm capturing its return 
> in an int and throwing an error about 
> the
> > >> return value not being int.  Then 
> the error service went into a loop
> > >> reporting its own internal error.  
> Good call.
> > >>
> > >> On Thu, May 19, 2016 at 8:17 AM, 
> Blain <blain20 at gmail.com> wrote:
> > >>
> > >> > It segfaults at the callother 
> with the function being static, and 
> works
> > >> > fine with the function not 
> being static.  It's possible that the 
> error
> > >> > messaging is getting stuck in a 
> loop, though.  I'll have to track that
> > >> down.
> > >> > On May 19, 2016 8:02 AM, 
> "Raymond Jennings" 
> <shentino at gmail.com> wrote:
> > >> >
> > >> >> That shouldn't cause a 
> segfault though.
> > >> >>
> > >> >> Calling a static function in 
> another object should at most fail
> > >> silently
> > >> >> with a nil return value.
> > >> >>
> > >> >> If you can run the core dump 
> through gdb and generate a stack trace 
> you
> > >> >> should send it to dworkin.
> > >> >>
> > >> >> The only reason dgd should 
> crash is infinite recursion.
> > >> >> 
> ______________________________________
> ______
> > >> >> 
> https://mail.dworkin.nl/mailman/listin
> fo/dgd
> > >> >
> > >> >
> > >> 
> ______________________________________
> ______
> > >> 
> https://mail.dworkin.nl/mailman/listin
> fo/dgd
> > >>
> > >
> > >
> > 
> ______________________________________
> ______
> > 
> https://mail.dworkin.nl/mailman/listin
> fo/dgd
> 
> --
> http://www.flickr.com/photos/mrobjecti
> ve/
> http://www.om-d.org/
> 
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/