Segfault with lastest master

[Rick Walsh]

Hi Dirk,

On 11 Jul 2015 11:03 pm, "Dirk Hohndel" <dirk at hohndel.org> wrote:
>
> 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.

Yes, I realized just about everything I wrote in that email was wrong.

>
> 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.

I think I have some idea.  First couple of lines of output are:

fullpath /bitmaps/default_location.png results in
fullpath /bitmaps/empty.png results in

It was looking for empty.png in /bitmaps instead of
/home/rick/build/subsurface/build/marbledata/bitmaps.  Obviously there
isn't a directory /bitmaps. So it looked for empty.png and got into a loop.

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150711/03357d79/attachment.html>