On 11 July 2015 at 12:09, Rick Walsh <rickmwa...@gmail.com> wrote: > > > On 11 July 2015 at 11:22, Dirk Hohndel <d...@hohndel.org> wrote: > >> >> >> On Jul 10, 2015, at 17:55, Rick Walsh <rickmwa...@gmail.com> wrote: >> >> >> >> On 11 July 2015 at 10:42, Dirk Hohndel <d...@hohndel.org> wrote: >> >>> On Sat, Jul 11, 2015 at 10:36:42AM +1000, Rick Walsh wrote: >>> > Hi Dirk, >>> > >>> > On 11 July 2015 at 10:29, Dirk Hohndel <d...@hohndel.org> wrote: >>> > >>> > > So this is an odd infinite recursion. I can clearly see how it could >>> > > happen - but if you have a current Subsurface it should not happen. >>> > > Let me guess, you updated marble but not Subsurface? >>> > > >>> > > Anyway, I have pushed a quick fix to marble/Subsurface-testing which >>> > > should address that silly problem. >>> > > >>> > > >>> > Thanks, you fix to marble works. >>> > >>> > But I am running the latest Subsurface master: >>> > commit d8ca04626589221c5f7c178e882cfaa4c095ce2a >>> >>> Strange. The only way the infinite recursion could have happened was if >>> you didn't have marbledata/bitmaps/empty.png >>> >> >> Interesting. I have empty.png there, and I can open it. >> >> >>> >>> Is there any reason why that would not be present in whatever path Marble >>> is looking in for you? Are you installing things locally? Are you running >>> out of your build tree? >>> >> >> The build.sh script installs everything to the install-root directory. >> Before running install-root/bin/subsurface I need to add install-root/lib >> to LD_LIBRARY. I've set up a script called start-subsurface to do this. >> >> Otherwise (and more often), I just run ./subsurface from inside >> subsurface/build. Neither way was working until your latest Marble patch. >> Both ways work now. >> >> >> I'd love to know why it didn't find empty.png... Can you recompile marble >> and add a #define DEBUG 1 to src/lib/marble/MarblePath.cpp ( that's from >> memory, I'm on my phone) >> > > Yes, the file is there. I added #define DEBUG 1 to MarblePath.cpp, re-ran > make in marble-source/build then again in subsurface/build. > > Is this the output you're interested in? > (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". > Map theme file does not exist: "" > QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No > such file or directory > [New Thread 0x7fff81bf9700 (LWP 19105)] > [Thread 0x7fff81bf9700 (LWP 19105) exited] > > Ah, I tell a lie. I can't find MarblePath.cpp. That output was after adding the debug line to MarbleMap.cpp, but perhaps my inability to read a file name could have been useful. Just a stab in the dark, but are we getting to here in MarbleMap.cpp? From line 709:
void MarbleMapPrivate::setDocument( QString key ) { if ( !m_model->mapTheme() ) { // Happens if no valid map theme is set or at application startup // if a file is passed via command line parameters and the last // map theme has not been loaded yet /** * @todo Do we need to queue the document and process it once a map * theme becomes available? */ return; } > Cheers, > > Rick > >
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface