Segfault

[Cristian Ionescu-Idbohrn]

On Wed, 13 Feb 2013, Jef Driesen wrote:
> On 2013-02-12 23:32, Cristian Ionescu-Idbohrn wrote:
> >
> > So, Jef.  Is there something you can recall?  Anything?
>
> Nothing special.

Thanks for the details, Jef.

> I just did a "git pull" followed by "make" as usual. No change in
> environment, compiler options, or anything like that.

Sounds like dependencies on source (header file) changes is not properly
detected.

> (The only change I have in my checkout is to adjust the path to the
> libdivecomputer library in the Makefile.)

That should not be needed if one places the 'libdivecomputer' and
'subsurface' source top tree directories next to each other, like:

	/path/to/source/libdivecomputer
	/path/to/source/subsurface

and:

	export LIBDCDEVEL=y

or execute:

	$ LIBDCDEVEL=y make

The subsurface Makefile rule (for static linking):

ifneq ($(LIBDCDEVEL),)
	LIBDIVECOMPUTERDIR = ../libdivecomputer
	LIBDIVECOMPUTERINCLUDES = -I$(LIBDIVECOMPUTERDIR)/include
	LIBDIVECOMPUTERARCHIVE = $(LIBDIVECOMPUTERDIR)/src/.libs/libdivecomputer.a

will find it.

It would be good to mention that in the README.  Very useful, IMO.

> I have absolutely no explanation on how it happened. Maybe it's indeed
> as Linus says some left over object file from the old manual dependency
> tracking?

Hmm...

> I find that hard to believe, because I update subsurface quite frequently.

See (dependencies on source changes) above.

> Anyway, what I can tell is how I discovered something was wrong. I was
> trying to track down where that bogus pointer was assigned. I noticed
> that the dive structure in one function was perfectly fine (e.g. a NULL
> pointer for the cylinder description), but the same structure (at the
> same memory address!) in another function suddenly had that bogus
> pointer. After the initial "What the hell is going on here?", the only
> reasonable explanation I could think of is that the definition of the
> dive structure had changed, and one object file was compiled with the
> old definition, and another with the new definition.

Now, that's really, really tricky, specially under development.  Things
like that (untracked header file dependencies) may lead (like in this
case) to _false_ bug reports.

	It's not worth it.

I lack that deep Makefile fu, but I'm sure there's a bunch of very
competent people out there that do have it, who would be thrilled to help
if asked for a little contribution ;)

> So I did a "make clean && make" and the problem was gone.

And that means a FAQ would be useful:

	Before you report a bug, do a "make clean && make" and try to
	reproduce it.

> I believe this is an isolated case, that is very unlikely to happen
> again and thus doesn't need any further investigation.

Well, Murphy was an optimist ;)


-- 
Cristian