[Date Prev][Date Next]
Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record
Hallvard Breien Furuseth:
> email@example.com writes:
> >Hallvard Breien Furuseth:
> >> /** User-settable callback for assert(), called before abort()
> >> * instead of printing the message.
> >> *
> >> * assert(some user errors) might be unaffected. This hack
> >> * should become obsolete as lmdb's error handling matures.
> >> * @param[in] msg The assertion message, not including newline.
> >> * @parem[in] info Currently NULL. Might change in the future.
> >> */
> >> extern void (*mdb_assert_cb)(char *msg, void *info);
> >> (Or maybe call it -before- printing the message, you can abort or
> >> longjmp yourself if you don't want the message.)
> > Looks good. I'll code up an example implementation to set and use
> > the callback. The "info" argument should be sufficient to figure
> > out which database is failing.
> To repeat, 'info' would be NULL initially. Does that make it useless to
> you? Various pieces of code don't know any context of interest to the
> user anyway.
That is unhelpful, as my opens lots of databases.
Instead I propose that for each open database I give you my function
pointer AND my context pointer. Then, you call my function with my
context pointer when there is a problem.
My program opens multiple databases. It is useless if you pass me
your LMDB handle, as I now have to find out a) which of all my open
databases is LMDB and b) which of those LMDB databases is messed up.
That totally breaks all abstractions.
> I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that
> compiles so it can report env, txn, dbi. Howard, should I do that?
That was my idea. Allow me to code up an example, it is simpler
than arguing in the abstract.