Segfault with lastest master

[Dirk Hohndel]

On Sat, Jul 11, 2015 at 05:11:31PM +1000, Rick Walsh wrote:
> >>
> >> Umm. Err. What? If the startup used to get you into the infinite recursion
> >> (that's what happens in the "return path("bimaps/empty.png");"...)
> >>
> >> Oh, never mind. I bet your libssrfmarble isn't compiled with debugging
> >> enabled, so the qDebug never gets printed for you.
> >>
> >> Can you replace the qDebug with
> >>
> >> fprintf(stderr, "fullpath %s results in %s\n", qPrintable(fullpath),
> >> qPrintable(result));
> >>
> >> (completely untested, typos and thinkos included free of charge... but
> >> something along those lines should work...)
> >
> > Now I need a beer and/or coffee.
> >
> > So after I actually built Subsurface against the Marble libs modified with
> > the fprintf(stderr... line., this does do something.
> >
> > (gdb) run
> > Starting program: /home/rick/build/subsurface/build/subsurface
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib64/libthread_db.so.1".
> > fullpath /bitmaps/empty.png results in
> > tried to open nonexistent file bitmaps/empty.png
> > fullpath /maps/earth/srtm2/srtm2.dgml results in
> > tried to open nonexistent file maps/earth/srtm2/srtm2.dgml
> > Map theme file does not exist: ""
> > fullpath
> > /home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.kml
> > results in
> > tried to open nonexistent file placemarks/cityplacemarks.kml
> > fullpath
> > /home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.cache
> > results in
> > tried to open nonexistent file placemarks/cityplacemarks.cache
> >
> > etc.
> >
> > It is looking for the files in the wrong place.  marbledata is a symbolic
> > link to:
> > /home/rick/build/subsurface/marbledata, when it needs to point to
> > /home/rick/build/marble-source/data.

Strangely, no. I realize this is kinda weird, so let me explain in a
little more detail.

Subsurface doesn't need all the different little icons and kml files that
Marble wants to show - we have a fairly small set that we want to see.
Those have been added to the Subsurface sources in marbledata/bitmaps

Marble is perfectly happy if any of the placemark data is missing. But
because of (frankly) bad programming inside Marble, if any of the bitmaps
in marbledata/bitmaps/ are missing (and we are missing most of them as we
don't want Marble to show those and clutter the globe) then Marble tries
to open a file named "" which Qt finds not funny and spews out a warning
about.

So this is what my patch is trying to address. If the file doesn't exist,
and if it's a bitmap, then return the path to bitmaps/empty.png.

So far, so good. For some reason that ended in an infinite recursion for
you. So that means it couldn't find bitmaps/empty.png either. But
empty.png should be in /home/rick/build/subsurface/marbledata/bitmaps,
correct?

So what I still don't get is "how could you have gotten that infinite
recursion?"

Sure, it's fixed, but it nags on me that I don't understand how you got
there.

Please remove the new symlink that you created as that just hides that in
an installed version of Subsurface a ton of these files wouldn't be there
as we don't include them.

> I think line 157 of CMakeLists.txt is guilty:
> if(NOT (insource OR insourcedir))
>     if(NOT NO_MARBLE)
>         add_custom_target(link_marble_data ALL COMMAND rm -f marbledata &&
> ln -s ${${PROJECT_NAME}_SOURCE_DIR}/marbledata
> ${${PROJECT_NAME}_BINARY_DIR}/marbledata)
>     endif()
> endif()
> 
> I'm not sure how to fix this

That code is correct. Linking into the Marble sources is just wrong.

The only reason we do this is so that you can run an out-of-tree built
version of Subsurface without needing to install it (which is pretty much
the only way I ever run Subsurface, unless I test the packages that I
build in a VM or on a different machine...)

/D