Segfault with lastest master
Rick Walsh
rickmwalsh at gmail.com
Fri Jul 10 19:18:12 PDT 2015
On 11 July 2015 at 12:09, Rick Walsh <rickmwalsh at gmail.com> wrote:
>
>
> On 11 July 2015 at 11:22, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>>
>>
>> On Jul 10, 2015, at 17:55, Rick Walsh <rickmwalsh at gmail.com> wrote:
>>
>>
>>
>> On 11 July 2015 at 10:42, Dirk Hohndel <dirk at 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 <dirk at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150711/a8b656a3/attachment.html>
More information about the subsurface
mailing list