Understanding SIGSEGV issues

[H. S. Teoh]

On Thu, Jan 10, 2019 at 01:09:22PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 1/10/19 12:30 PM, Russel Winder wrote:
> > On Thu, 2019-01-10 at 10:00 -0500, Steven Schveighoffer via Digitalmars-d-
> > learn wrote:
> > […]
> > > Hm... your description of having the problem happen at the end of
> > > main seems to suggest it has something to do with destruction.
> > > 
> > 
> > It seems that there was a change in one file of libdvbv5 1.14.x →
> > 1..16.y that introduced a breaking change wrt the D binding. I did a
> > regeneration using DStep, didn't notice anything significant, and
> > yet everything now works again.  So it was very significant.
> > 
> > The underlying problem here was that I had failed to notice the
> > upgrade of libdvbv5!
> > 
> 
> That is one problem with linking against C or C++ code -- changes to
> certain things (e.g. struct layout) don't change the mangling.

Yeah, this is the same problem with shared library soname versioning on
Posix.  Technically everytime the ABI changes the version must be
bumped, but since this is not automated, it's prone to human error, or
rather, negligence.

It makes one wonder if there should somehow be a way of encapsulating
the changes to the ABI in a way that can be automatically checked. (It
has to be automatic, otherwise it would be too onerous and nobody would
do it in practice.)

The most obvious way is to mangle the field types of the struct as part
of the struct's mangled name, though this does introduce a lot of symbol
bloat (and may need another round of ridiculously-long symbol names that
need some manner of compression to keep under control).  Barring that,
perhaps some kind of low-collision hash of the struct contents where the
kind of small changes that tend to happen in code will be highly
unlikely to collide, so any such changes will be easily detected.  If
one were paranoid, one could use cryptographic hashes for pretty much
guaranteeing uniqueness, but that'd be total overkill.

//

OTOH, perhaps the more pertinent issue here is that the bindings were
generated *manually as a separate step* outside of the build system.
Ideally, you'd automate the generation of bindings as part of your
build, so that they will *always* be up-to-date.  I'm a big fan of
automation, because this is the kind of tedious housekeeping that humans
are really, really good at forgetting and/or screwing up.

(Side-note: and this is why I insist that my build systems must support
generic dependency building. All these sorts of tasks *need* to be part
of the build rather than done by hand, precisely to prevent these sorts
of time-wasting, head-scratching mishaps.)


> You may want to consider using dpp instead if possible.
[...]

Or this.  Which is essentially equivalent to automatically generating
bindings.


T

-- 
Маленькие детки - маленькие бедки.