[openssl-dev] OS X 10.8, x86_64: 01-test_abort.t... sh: line 1: 71522 Abort trap: 6

[Richard Levitte]

In message <CAH8yC8nWF5N7rOu-+2aJC1aHhkJDEB-g746eyTVfbQnUra-ATQ at mail.gmail.com> on Sat, 19 Mar 2016 20:09:34 -0400, Jeffrey Walton <noloader at gmail.com> said:

noloader> > noloader> Allowing a library to make policy decisions for the application is a
noloader> > noloader> philosophical debate.
noloader> >
noloader> > The few places we're using something that drastic is when the internal
noloader> > structures can only be seen as corrupt by our own fault.  That's a
noloader> > point where you can expect things to go crashing any time, or just
noloader> > becoming *more* corrupt.  The application cannot make a policy
noloader> > decision at that point, as the virtual rugg has already been pulled
noloader> > from under everyone's feet.
noloader> 
noloader> Then why not call exit() rather than abort()? (Regardless of what you
noloader> do here, its going to violate Apple's App Store policies and probably
noloader> cause a rejection).

I just grepped through the source, and we never call OPENSSL_die()
directly, we do it via OPENSSL_assert() (well, except for that test
program, but the effect is the same for the purpose of that test)

Point is, if any of the the assertions are triggered into faulting,
there's a but in the library and it shouldn't get released.  That's
the whole point.  The tests are supposed to catch those and basically
raise a big red flag.

Are you telling me that according to Apple's App Store policies,
assertions must not be used?

noloader> Also, when configured with -d, that kind of puts you in a debug
noloader> configuration. What's the purpose of crashing when the program is
noloader> under a debugger? It seems like a raise(SIGTRAP) to snap the debugger
noloader> would be a better choice.

Well...  the implementation of OPENSSL_assert() mimics the
implementation of assert().

noloader> How many times has a user submitted a core dump from an abort()?
noloader> I'm guessing very few, and they probably got a curt response from the dev
noloader> team.

Nope, no coredumps, but we do get reports about the failed assertion
messages.  There was some reported not so long ago, because a couple
of assertions I had added were a bit overzealous...  but they did also
lead us to find a couple bugs in a CRTL.

Other than that report, I can't remember when I last saw one.  If the
library crashes with an assertion failure, I would expect that to be
reported, about the same way as a failing "make depend" or other
build.  If such reports are few and far apart, one might also think
that's how often those assertion do fail, or that we've caught them
ourselves first.

noloader> How many times has OpenSSL perused Apple's, Microsoft's, or <favorite
noloader> distros> error reporting website, and opened tickets based on the
noloader> error reports? I'm guessing 0.

I would believe that when we find errors in other libraries, we do
report them if possible.  I recently reported a couple of faults in
the VMS C RTL (yup, that's the one I mentioned above).

noloader> How many times does the report egress data? 100% of the time.
noloader> 
noloader> On the more sarcastic side, NSA, GCHQ and law enforcement has probably
noloader> browsed those reports more than the folks they are supposedly provided
noloader> for.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/