[DGD] Segfault

[bart at wotf.org]

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/