Re: Segfault with lastest master
Hi Dirk,
On 11 July 2015 at 15:05, Dirk Hohndel d...@hohndel.org wrote:
On Sat, Jul 11, 2015 at 02:59:17PM +1000, Rick Walsh wrote:
On 11 July 2015 at 12:48, Dirk Hohndel d...@hohndel.org wrote:
Nope. MarbleDirs.cpp
And actually why don't you use this patch...
diff --git a/src/lib/marble/MarbleDirs.cpp
b/src/lib/marble/MarbleDirs.cpp
index 014ab0582d0b..734107f6536e 100644
--- a/src/lib/marble/MarbleDirs.cpp
+++ b/src/lib/marble/MarbleDirs.cpp
@@ -68,6 +68,7 @@ QString MarbleDirs::path( const QString
relativePath )
}
QString result = QDir( fullpath ).canonicalPath();
if (result.isEmpty()) {
+ qDebug() fullpath result result;
if (relativePath.contains(bitmaps) relativePath !=
bitmaps/empty.png)
return path(bitmaps/empty.png);
#if defined(DEBUG)
I've just tried that but I'm not sure it's doing much.
(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 20213)]
[Thread 0x7fff81bf9700 (LWP 20213) exited]
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.
I recreated the link to point where it should, and the error messages go
away.
Rick
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 1/1] Add new functions to list of exported symbols
On 11 Jul 2015, at 6:55, Dirk Hohndel d...@hohndel.org wrote: On Fri, Jul 10, 2015 at 05:10:01PM -1000, Gaetan Bisson wrote: Hi Dirk, I'm shamelessly bumping my proposed patch to libdc/Subsurface-testing from earlier, this time as a thread-starter with [PATCH] in the Subject... :) Smart man. You know EXACTLY how this works. Thanks for the patch. Pushed to the Subsurface-testing branch. Dirk, it appears that you pushed that to the Subsurface-testing branch under libdivecomputer. The build script pulls the Subsurface-testing branch from libdc. Either we need to update the build script or you pushed it to the wrong branch. /Jocke ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault with lastest master
On 11 July 2015 at 16:44, Rick Walsh rickmwa...@gmail.com wrote:
Hi Dirk,
On 11 July 2015 at 15:05, Dirk Hohndel d...@hohndel.org wrote:
On Sat, Jul 11, 2015 at 02:59:17PM +1000, Rick Walsh wrote:
On 11 July 2015 at 12:48, Dirk Hohndel d...@hohndel.org wrote:
Nope. MarbleDirs.cpp
And actually why don't you use this patch...
diff --git a/src/lib/marble/MarbleDirs.cpp
b/src/lib/marble/MarbleDirs.cpp
index 014ab0582d0b..734107f6536e 100644
--- a/src/lib/marble/MarbleDirs.cpp
+++ b/src/lib/marble/MarbleDirs.cpp
@@ -68,6 +68,7 @@ QString MarbleDirs::path( const QString
relativePath )
}
QString result = QDir( fullpath ).canonicalPath();
if (result.isEmpty()) {
+ qDebug() fullpath result result;
if (relativePath.contains(bitmaps) relativePath !=
bitmaps/empty.png)
return path(bitmaps/empty.png);
#if defined(DEBUG)
I've just tried that but I'm not sure it's doing much.
(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 20213)]
[Thread 0x7fff81bf9700 (LWP 20213) exited]
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.
I recreated the link to point where it should, and the error messages go
away.
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
Rick
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault with lastest master
On 11 July 2015 at 16:44, Rick Walsh rickmwa...@gmail.com wrote:
Hi Dirk,
On 11 July 2015 at 15:05, Dirk Hohndel d...@hohndel.org wrote:
On Sat, Jul 11, 2015 at 02:59:17PM +1000, Rick Walsh wrote:
On 11 July 2015 at 12:48, Dirk Hohndel d...@hohndel.org wrote:
Nope. MarbleDirs.cpp
And actually why don't you use this patch...
diff --git a/src/lib/marble/MarbleDirs.cpp
b/src/lib/marble/MarbleDirs.cpp
index 014ab0582d0b..734107f6536e 100644
--- a/src/lib/marble/MarbleDirs.cpp
+++ b/src/lib/marble/MarbleDirs.cpp
@@ -68,6 +68,7 @@ QString MarbleDirs::path( const QString
relativePath )
}
QString result = QDir( fullpath ).canonicalPath();
if (result.isEmpty()) {
+ qDebug() fullpath result result;
if (relativePath.contains(bitmaps) relativePath !=
bitmaps/empty.png)
return path(bitmaps/empty.png);
#if defined(DEBUG)
I've just tried that but I'm not sure it's doing much.
(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 20213)]
[Thread 0x7fff81bf9700 (LWP 20213) exited]
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.
I recreated the link to point where it should, and the error messages go
away.
Can I recall that email? The link points where it should.
I can see a few problems in the output. First is that rather than trying
to open /home/rick/build/subsurface/build/marbledata/bitmaps/xxx it's
trying to open /bitmaps/xxx
Next, it's trying to open kml files in the placemarks directory, which
doesn't exist.
And thirdly, it's trying to open bitmap files that don't exist.
Full output is:
fullpath /bitmaps/default_location.png results in
fullpath /bitmaps/empty.png results in
fullpath /maps/earth/srtm2/srtm2.dgml results in
Map theme file does not exist:
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No
such file or directory
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.kml
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.cache
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/boundaryplacemarks.kml
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/boundaryplacemarks.cache
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/otherplacemarks.kml
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/otherplacemarks.cache
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/elevplacemarks.kml
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/elevplacemarks.cache
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/baseplacemarks.kml
results in
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/baseplacemarks.cache
results in
fullpath /home/rick/build/subsurface/build/marbledata/bitmaps/other.png
results in
fullpath
/home/rick/build/subsurface/build/marbledata/bitmaps/observatory.png
results in
fullpath
words to think about
I saw this on Twitter and feel compelled to share this here. Sorry, not a cute cat pictures but the Development Ideology of a completely unrelated project. From https://github.com/WhisperSystems/TextSecure/blob/master/contributing.md Development Ideology Truths which we believe to be self-evident: - The answer is not more options. If you feel compelled to add a preference that's exposed to the user, it's very possible you've made a wrong turn somewhere. - The user doesn't know what a key is. We need to minimize the points at which a user is exposed to this sort of terminology as extremely as possible. - There are no power users. The idea that some users understand concepts better than others has proven to be, for the most part, false. If anything, power users are more dangerous than the rest, and we should avoid exposing dangerous functionality to them. - If it's like PGP, it's wrong. PGP is our spirit guide for what not to do. - It's an asynchronous world. Be wary of anything that is anti-asynchronous: ACKs, protocol confirmations, or any protocol-level advisory message. - There is no such thing as time. Protocol ideas that require synchronized clocks are doomed to failure. Now admittedly, some of these don't apply to us. But the first one I think we really need to take to hard. We have way too many options already and we keep adding more. And we keep adding them because of our believe in power users. And we make Subsurface harder and harder to use for normal people because we try to cater to those alleged power users. Number two is also important. Just replace key with git when it comes to our cloud storage. And I'm sure there are some other issues where we should apply that same principle. As far as our UI is concerned, I'd like to rephrase number 4. If it's like Diving Log then it is wrong. Diving Log is our spirit guide for what not to do :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 1/1] Add new functions to list of exported symbols
On Sat, Jul 11, 2015 at 09:45:22AM +0200, Joakim Bygdell wrote: On 11 Jul 2015, at 6:55, Dirk Hohndel d...@hohndel.org wrote: On Fri, Jul 10, 2015 at 05:10:01PM -1000, Gaetan Bisson wrote: Hi Dirk, I'm shamelessly bumping my proposed patch to libdc/Subsurface-testing from earlier, this time as a thread-starter with [PATCH] in the Subject... :) Smart man. You know EXACTLY how this works. Thanks for the patch. Pushed to the Subsurface-testing branch. Dirk, it appears that you pushed that to the Subsurface-testing branch under libdivecomputer. The build script pulls the Subsurface-testing branch from libdc. Either we need to update the build script or you pushed it to the wrong branch. Last night I should have stayed away from my computer, I think... Thanks for catching this stupid mistake. This is now fixed. The Subsurface-testing branch once again has been removed from libdivecomputer and libdc's Subsurface-testing branch has been updated to include Gaetan's patch. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault with lastest master
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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault with lastest master
Hi Dirk,
On 11 Jul 2015 11:03 pm, Dirk Hohndel d...@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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: different segfault with lastest master
On Saturday 11 July 2015 19:28:42 Tomaz Canabrava wrote: On Sat, Jul 11, 2015 at 7:00 PM, Linus Torvalds torva...@linux-foundation.org wrote: #0 0x7fffefa67a98 in raise () at /lib64/libc.so.6 #1 0x7fffefa6972a in abort () at /lib64/libc.so.6 #2 0x7fffefaaaea2 in () at /lib64/libc.so.6 #3 0x7fffefab3ef8 in _int_malloc () at /lib64/libc.so.6 #4 0x7fffefab6b5e in malloc () at /lib64/libc.so.6 #5 0x7042d453 in QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlagsQArrayData::AllocationOption) () at /lib64/libQt5Core.so.5 #6 0x704b9b1f in QString::QString(int, QChar) () at /lib64/libQt5Core.so.5 #7 0x704978f7 in QLocalePrivate::dateTimeToString(QString const, QDateTime const, QDate const, QTime const, QLocale const*) const () at /lib64/libQt5Core.so.5 This crash is not related to subsurface but to Qt, I'm not sure what happened there but did you updated your Qt and didn`t compiled Subsurface after update? The #13 0x71693668 in QDateTimeEdit::setTime(QTime const) () line tells me that this Qt fault, we are passing a stack variable to a QDateTime and it`s getting corrupted inside an internal impelmentation of QArrayData Thiago? It crashed inside malloc, so the problem is not in the stack trace. Something corrupted the malloc structures. Valgrind would have been the best, but didn't work... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault with lastest master
Hi Dirk,
On 11 July 2015 at 23:11, Dirk Hohndel d...@hohndel.org wrote:
On Sat, Jul 11, 2015 at 07:16:32PM +1000, Rick Walsh wrote:
Full output is:
fullpath /bitmaps/default_location.png results in
fullpath /bitmaps/empty.png results in
Yeah, so this is the one that used to cause you the crash.
It somehow tried to open the default_location.png file before internally
the paths were set up correctly. And then it didn't find the empty.png
file, either, and went into infinite recursion.
But this gives me something to work with to understand why it would do
such a thing for you but not for me in my testing.
Thanks for helping to track this down.
I think I've tracked down the problem. The short answer is that the
problem is me. Quite clearly this has not been my weekend. First my
attempt at data collection exercise was foiled. And by that I mean our
lovely Melbourne winter made our seas too windy and/or rough for me to dive
a wreck in the Ships' Graveyard, sitting 45m - perfect for my deco course.
I assume I must have had old files in my subsurface build directory so
something was compiled without MARBLE_DATA_PATH defined, or
MARBLE_DATA_PATH was set to something incorrect.
Now the long answer:
From MarbleDirs.cpp:
QString MarbleDirs::path( const QString relativePath )
{
QString localpath = localPath() + '/' + relativePath;// local path
QString systempath = systemPath() + '/' + relativePath;// system
path
QString fullpath = systempath;
...
And from running subsurface with the MarbelDirs::path() debugging:
[rick@localhost build]$ ./subsurface
fullpath /bitmaps/default_location.png results in
fullpath /bitmaps/empty.png results in
fullpath /maps/earth/srtm2/srtm2.dgml results in
This essentially says that systemPath() is returning empty. So I added
debugging lines to the MarbleDirs::systemPath() function to work out where
it was going wrong (not a patch, just showing what I changed):
QString MarbleDirs::systemPath()
{
QString systempath;
#ifdef Q_OS_MACX
...
if ( QFile::exists( systempath ) ){
+fprintf(stderr, systempath returned: %s\n, qPrintable(systempath));
return systempath;
}
#endif // mac bundle
// Should this happen before the Mac bundle already?
if ( !runTimeMarbleDataPath.isEmpty() ) {
+fprintf(stderr, runTimeMarbleDataPath returned: %s\n,
qPrintable(runTimeMarbleDataPath));
return runTimeMarbleDataPath;
}
#ifdef MARBLE_DATA_PATH
//MARBLE_DATA_PATH is a compiler define set by cmake
QString compileTimeMarbleDataPath(MARBLE_DATA_PATH);
if(QDir(compileTimeMarbleDataPath).exists()) {
+fprintf(stderr, compileTimeMarbleDataPath returned: %s\n,
qPrintable(compileTimeMarbleDataPath));
return compileTimeMarbleDataPath;
}
#endif // MARBLE_DATA_PATH
-return QDir( QCoreApplication::applicationDirPath()
QString QDirString = QDir( QCoreApplication::applicationDirPath()
#if defined(QTONLY)
+ QLatin1String( /data )
#else
+ QLatin1String( /../share/apps/marble/data )
#endif
).canonicalPath();
+fprintf(stderr, QDirString returned: %s\n, qPrintable(QDirString));
+return QDirString;
}
With this compiled, the output was:
[rick@localhost build]$ ./subsurface
QDirString returned:
fullpath /bitmaps/default_location.png results in
QDirString returned:
fullpath /bitmaps/empty.png results in
QDirString returned:
fullpath /maps/earth/srtm2/srtm2.dgml results in
Map theme file does not exist:
QDirString returned:
QDirString returned:
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No
such file or directory
QDirString returned:
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.kml
results in
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
fullpath
/home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.cache
results in
runTimeMarbleDataPath returned: /home/rick/build/subsurface/build/marbledata
So something being executed early when Subsurface starts appears to have
been compiled without MARBLE_DATA_PATH defined correctly. So I nuked the
contents of /home/rick/build/subsurface/build/, and rebuilt Subsurface
(based on the build.sh script, but only building Subsurface because I
didn't want to re-download Marble and lose the debugging lines). Now it's
running without a problem, and not even looking for
Re: different segfault with lastest master
On Sat, Jul 11, 2015 at 7:00 PM, Linus Torvalds torva...@linux-foundation.org wrote: Hmm. I'm not sure how to reproduce this, because I was just moving around between the dives, checking out how the globe moved, and occasionally pressing the dive site quick-edit button. And suddenly I get *** Error in `/home/torvalds/src/install-root/bin/subsurface': malloc(): memory corruption (fast): 0x05a9f01f *** with the call stack being #0 0x7fffefa67a98 in raise () at /lib64/libc.so.6 #1 0x7fffefa6972a in abort () at /lib64/libc.so.6 #2 0x7fffefaaaea2 in () at /lib64/libc.so.6 #3 0x7fffefab3ef8 in _int_malloc () at /lib64/libc.so.6 #4 0x7fffefab6b5e in malloc () at /lib64/libc.so.6 #5 0x7042d453 in QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlagsQArrayData::AllocationOption) () at /lib64/libQt5Core.so.5 #6 0x704b9b1f in QString::QString(int, QChar) () at /lib64/libQt5Core.so.5 #7 0x704978f7 in QLocalePrivate::dateTimeToString(QString const, QDateTime const, QDate const, QTime const, QLocale const*) const () at /lib64/libQt5Core.so.5 #8 0x7049867e in QLocale::toString(QDateTime const, QString const) const () at /lib64/libQt5Core.so.5 #9 0x71692e64 in QDateTimeEdit::textFromDateTime(QDateTime const) const () at /lib64/libQt5Widgets.so.5 #10 0x71692d63 in QDateTimeEditPrivate::textFromValue(QVariant const) const () at /lib64/libQt5Widgets.so.5 #11 0x7169341b in QDateTimeEditPrivate::updateEdit() () at /lib64/libQt5Widgets.so.5 #12 0x7167815c in QAbstractSpinBoxPrivate::setValue(QVariant const, EmitPolicy, bool) () at /lib64/libQt5Widgets.so.5 #13 0x71693668 in QDateTimeEdit::setTime(QTime const) () at /lib64/libQt5Widgets.so.5 #14 0x005e3f19 in MainTab::updateDiveInfo(bool) (this=0xeed8a0, clear=false) at /home/torvalds/src/subsurface/qt-ui/maintab.cpp:539 #15 0x004fafd0 in MainWindow::current_dive_changed(int) (this=0xdadfb0, divenr=469) at /home/torvalds/src/subsurface/qt-ui/mainwindow.cpp:268 ... which doesn't look very interesting. The corruption probably happened at some earlier point. I tried to run it under valgrind in case that shows anything more interesting, but that actually crashed very quickly in WTFCrash with address 0xbbadbeef, which seems to be some WebKit issue with valgrind. Googling valgrind and WTFCrash and 0xbbadbeef implies I'm not the only one, but it makes valgrind not give anything useful for this. Sorry for useless bug report. I don't know what else to try. Linus, This crash is not related to subsurface but to Qt, I'm not sure what happened there but did you updated your Qt and didn`t compiled Subsurface after update? The #13 0x71693668 in QDateTimeEdit::setTime(QTime const) () line tells me that this Qt fault, we are passing a stack variable to a QDateTime and it`s getting corrupted inside an internal impelmentation of QArrayData Thiago? Tomaz Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: different segfault with lastest master
Compile with no Facebook, no user manual which stops the crash. You still get two bazillion errors from marble which mostly seem bogus to me but occasionally one can spot an actual bug in the midst of all that crap. Or compile with no marble as well to see if you can make something interesting show up. ccmake . in your build directory is your friend /D -- Sent from my phone On Jul 11, 2015, at 15:00, Linus Torvalds torva...@linux-foundation.org wrote: Hmm. I'm not sure how to reproduce this, because I was just moving around between the dives, checking out how the globe moved, and occasionally pressing the dive site quick-edit button. And suddenly I get *** Error in `/home/torvalds/src/install-root/bin/subsurface': malloc(): memory corruption (fast): 0x05a9f01f *** with the call stack being #0 0x7fffefa67a98 in raise () at /lib64/libc.so.6 #1 0x7fffefa6972a in abort () at /lib64/libc.so.6 #2 0x7fffefaaaea2 in () at /lib64/libc.so.6 #3 0x7fffefab3ef8 in _int_malloc () at /lib64/libc.so.6 #4 0x7fffefab6b5e in malloc () at /lib64/libc.so.6 #5 0x7042d453 in QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlagsQArrayData::AllocationOption) () at /lib64/libQt5Core.so.5 #6 0x704b9b1f in QString::QString(int, QChar) () at /lib64/libQt5Core.so.5 #7 0x704978f7 in QLocalePrivate::dateTimeToString(QString const, QDateTime const, QDate const, QTime const, QLocale const*) const () at /lib64/libQt5Core.so.5 #8 0x7049867e in QLocale::toString(QDateTime const, QString const) const () at /lib64/libQt5Core.so.5 #9 0x71692e64 in QDateTimeEdit::textFromDateTime(QDateTime const) const () at /lib64/libQt5Widgets.so.5 #10 0x71692d63 in QDateTimeEditPrivate::textFromValue(QVariant const) const () at /lib64/libQt5Widgets.so.5 #11 0x7169341b in QDateTimeEditPrivate::updateEdit() () at /lib64/libQt5Widgets.so.5 #12 0x7167815c in QAbstractSpinBoxPrivate::setValue(QVariant const, EmitPolicy, bool) () at /lib64/libQt5Widgets.so.5 #13 0x71693668 in QDateTimeEdit::setTime(QTime const) () at /lib64/libQt5Widgets.so.5 #14 0x005e3f19 in MainTab::updateDiveInfo(bool) (this=0xeed8a0, clear=false) at /home/torvalds/src/subsurface/qt-ui/maintab.cpp:539 #15 0x004fafd0 in MainWindow::current_dive_changed(int) (this=0xdadfb0, divenr=469) at /home/torvalds/src/subsurface/qt-ui/mainwindow.cpp:268 ... which doesn't look very interesting. The corruption probably happened at some earlier point. I tried to run it under valgrind in case that shows anything more interesting, but that actually crashed very quickly in WTFCrash with address 0xbbadbeef, which seems to be some WebKit issue with valgrind. Googling valgrind and WTFCrash and 0xbbadbeef implies I'm not the only one, but it makes valgrind not give anything useful for this. Sorry for useless bug report. I don't know what else to try. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: different segfault with lastest master
On Sat, Jul 11, 2015 at 3:45 PM, Dirk Hohndel d...@hohndel.org wrote: Compile with no Facebook, no user manual which stops the crash. You still get two bazillion errors from marble which mostly seem bogus to me but occasionally one can spot an actual bug in the midst of all that crap. Or compile with no marble as well to see if you can make something interesting show up. ccmake . in your build directory is your friend Hmm. that just does In file included from /home/torvalds/src/subsurface/qt-ui/printdialog.h:8:0, from /home/torvalds/src/subsurface/qt-ui/mainwindow.cpp:31: /home/torvalds/src/subsurface/./printer.h:5:20: fatal error: QWebView: No such file or directory compilation terminated. so apparently printing support needs QWebKit too, but the build rules turn it off when you turn FB and manual support. And I can't seem to turn on NO_PRINTING. Or rather, I can, but it doesn't stick. .. Oh. I see why. I'm using the build script, and that forces NO_PRINTING off. Anyway, that makes things runnable with valgrind, although very slow. I'm not seeing anything suspicious. I'll play with it some more. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
different segfault with lastest master
Hmm. I'm not sure how to reproduce this, because I was just moving around between the dives, checking out how the globe moved, and occasionally pressing the dive site quick-edit button. And suddenly I get *** Error in `/home/torvalds/src/install-root/bin/subsurface': malloc(): memory corruption (fast): 0x05a9f01f *** with the call stack being #0 0x7fffefa67a98 in raise () at /lib64/libc.so.6 #1 0x7fffefa6972a in abort () at /lib64/libc.so.6 #2 0x7fffefaaaea2 in () at /lib64/libc.so.6 #3 0x7fffefab3ef8 in _int_malloc () at /lib64/libc.so.6 #4 0x7fffefab6b5e in malloc () at /lib64/libc.so.6 #5 0x7042d453 in QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlagsQArrayData::AllocationOption) () at /lib64/libQt5Core.so.5 #6 0x704b9b1f in QString::QString(int, QChar) () at /lib64/libQt5Core.so.5 #7 0x704978f7 in QLocalePrivate::dateTimeToString(QString const, QDateTime const, QDate const, QTime const, QLocale const*) const () at /lib64/libQt5Core.so.5 #8 0x7049867e in QLocale::toString(QDateTime const, QString const) const () at /lib64/libQt5Core.so.5 #9 0x71692e64 in QDateTimeEdit::textFromDateTime(QDateTime const) const () at /lib64/libQt5Widgets.so.5 #10 0x71692d63 in QDateTimeEditPrivate::textFromValue(QVariant const) const () at /lib64/libQt5Widgets.so.5 #11 0x7169341b in QDateTimeEditPrivate::updateEdit() () at /lib64/libQt5Widgets.so.5 #12 0x7167815c in QAbstractSpinBoxPrivate::setValue(QVariant const, EmitPolicy, bool) () at /lib64/libQt5Widgets.so.5 #13 0x71693668 in QDateTimeEdit::setTime(QTime const) () at /lib64/libQt5Widgets.so.5 #14 0x005e3f19 in MainTab::updateDiveInfo(bool) (this=0xeed8a0, clear=false) at /home/torvalds/src/subsurface/qt-ui/maintab.cpp:539 #15 0x004fafd0 in MainWindow::current_dive_changed(int) (this=0xdadfb0, divenr=469) at /home/torvalds/src/subsurface/qt-ui/mainwindow.cpp:268 ... which doesn't look very interesting. The corruption probably happened at some earlier point. I tried to run it under valgrind in case that shows anything more interesting, but that actually crashed very quickly in WTFCrash with address 0xbbadbeef, which seems to be some WebKit issue with valgrind. Googling valgrind and WTFCrash and 0xbbadbeef implies I'm not the only one, but it makes valgrind not give anything useful for this. Sorry for useless bug report. I don't know what else to try. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: different segfault with lastest master
On Sat, Jul 11, 2015 at 4:29 PM, Linus Torvalds torva...@linux-foundation.org wrote: Anyway, that makes things runnable with valgrind, although very slow. I'm not seeing anything suspicious. I'll play with it some more. .. and immediately after sending that, I played some more with the quick-edit button (but no actual editing, just showing and hiding the quick-edit thing) and got several invalid writes . Attaching the relevant portion of the report, but it's lines 155-157 of ReverseGeoLookupThread::run() (divesitehelpers.cpp which is just the taxonomy.category writes. Looks like it writes past the end of the allocation. Linus valgrind-report Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
