Crash when saving geocache (with changed name)

Issue #470 resolved
wthaemelt created an issue

Steps to reproduce a QMS crash:

  • Start QMS
  • Load attached GPX file with geocache
  • Open edit window for geocache project name
  • Unlock to allow editing
  • Change name of geocache by appending a few letters
  • Select Save as and confirm some GPX filename
  • Next step: crash
  • Remarks:
  • ‌ This crash doesn’t happen with a normal waypoint and doesn’t happen for all geocaches!
  • ‌ The crash happens even without editing the geocache
  • ‌ The crash doesn’t happen when saving into a QMS or TCX file

Continuation with current @pingurus version:

  • Open the attached GPX file in the workspace
  • Type attributes within the search field
  • Crash

Comments (14)

  1. wthaemelt reporter
    • edited description

    Steps to reproduce a QMS crash:

    • Start QMS
    • Load attached GPX file with geocache
    • Open edit window for geocache project name
    • Unlock to allow editing
    • Change name of geocache by appending a few letters
    • Select Save as and confirm some GPX filename
    • Next step: crash
    • Remarks:
    • ‌ This crash doesn’t happen with a normal waypoint and doesn’t happen for all geocaches!
    • ‌ The crash happens even without editing the geocache
    • ‌ The crash doesn’t happen when saving into a QMS or TCX file
  2. wthaemelt reporter

    Would be glad I could do so. All I learnt up to now from Microsoft pages is “This feature is not available in Windows 10, version 1507 and later versions of the WDK.”. What I can see is “Ausnahme ausgelöst bei 0x00007FFB462B45D6 (Qt5Core.dll) in qmapshack_reldbg.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x0000000000000000.” I could not yet find a hint how to get the stack with the current OS/MSVC version.

  3. wthaemelt reporter

    Remove the line

     <groundspeak:attribute id="130" inc="1">Point of interest</groundspeak:attribute>
    

    from the GPX file. Then saving is no problem.

    @pingurus : My guess is that the id 130 is causing the crash. This id is not in the list of feasible ids used (Does this list already exist in the default branch? Maybe, in the form of a list of icon files using the id as name (but 130.png exists?). This line is read and the corresponding attribute is silently not shown in the edit/info window of the geocache. But saving this attribute leads to a crash.

    Remark: This was tested with the QMS default branch!

    Please goto line 700 in src\qmapshack\gis\gpx\serialization.cpp

            QDomText text = xmlCache.ownerDocument().createTextNode(geocache.attributeMeanings[attribute]);
    

    This seems to be the line causing the crash.

  4. wthaemelt reporter

    And here is finally the call stack:

    >   qmapshack_reldbg.exe!CGisItemWpt::writeGcExt(QDomNode & xmlCache) Zeile 700 C++
        qmapshack_reldbg.exe!CGisItemWpt::save(QDomNode & gpx, bool strictGpx11) Zeile 613  C++
        qmapshack_reldbg.exe!CGpxProject::saveAs(const QString & fn, IGisProject & project, bool strictGpx11) Zeile 321 C++
        qmapshack_reldbg.exe!IGisProject::saveAs(QString fn, QString filter) Zeile 455  C++
        qmapshack_reldbg.exe!CGisListWks::slotSaveAsProject() Zeile 1496    C++
        qmapshack_reldbg.exe!CGisListWks::qt_static_metacall(QObject * _o, QMetaObject::Call _c, int _id, void * * _a) Zeile 275    C++
        [Externer Code] 
        qmapshack_reldbg.exe!CGisListWks::showMenuProjectWks(const QPoint & p) Zeile 1009   C++
        qmapshack_reldbg.exe!CGisListWks::slotContextMenu(const QPoint & point) Zeile 1282  C++
        qmapshack_reldbg.exe!QtPrivate::QSlotObject<void (__cdecl CGisListWks::*)(QPoint const &),QtPrivate::List<QPoint const &>,void>::impl(int which, QtPrivate::QSlotObjectBase * this_, QObject * r, void * * a, bool * ret) Zeile 414 C++
        [Externer Code] 
        qmapshack_reldbg.exe!main(int argc, char * * argv) Zeile 83 C++
        [Externer Code] 
    
  5. wthaemelt reporter

    And here is the call stack for the attributes with crash (using pingurus branch)

        Qt5Core.dll!00007ffb411145d6()  Unbekannt
    >   qmapshack_reldbg_ping.exe!operator+(const QString & s1={...}, const char * s2=0x00007ff68c34d1c0) Zeile 1357    C++
        qmapshack_reldbg_ping.exe!CGisItemWpt::initKeywordLambdaMap::__l2::<Lambda>(CGisItemWpt * item=0x0000017cf625b5e0) Zeile 1221   C++
        [Externer Code] 
        qmapshack_reldbg_ping.exe!CGisItemWpt::getValueByKeyword(searchProperty_e keyword=eSearchPropertyGeocacheAttributes) Zeile 967  C++
        qmapshack_reldbg_ping.exe!CSearch::getSearchResult(IGisItem * item=0x0000017cf625b5e0) Zeile 172    C++
        qmapshack_reldbg_ping.exe!IGisProject::filter(const QString & str={...}) Zeile 1199 C++
        qmapshack_reldbg_ping.exe!CGisWorkspace::slotSearch(const QString & str={...}) Zeile 170    C++
        qmapshack_reldbg_ping.exe!QtPrivate::QSlotObject<void (__cdecl CGisWorkspace::*)(QString const &),QtPrivate::List<QString const &>,void>::impl(int which=1, QtPrivate::QSlotObjectBase * this_=0x0000017c33c6af90, QObject * r=0x0000017c33c65770, void * * a=0x00000035d114a9f8, bool * ret=0x0000000000000000) Zeile 414  C++
        [Externer Code] 
        qmapshack_reldbg_ping.exe!main(int argc=1, char * * argv=0x0000017c2a211830) Zeile 83   C++
        [Externer Code] 
    

    Could there be the same reason as with the other crash: not identified/handled id 130 is causing the crash?

    The line 1357 seems to be in qstring.h(?)

  6. wthaemelt reporter

    @pingurus: Looking at line 1221 in CGisItemWpt leads immediately to the line 1219. Obviously, this line is related to the topic "Negation of an attribute and its translation" earlier mentioned elsewhere. From this line I conclude that the text for a negated attribute should have the form No+ positive attribute text whereas No and the positive text will be translated. This construction is ok for the English language. But the translation will be difficult: Take German as an example. Here are several choices for No: "Nicht", "Nein", "Kein", ... and now take a composition `Dogs ->`Hunde ->`Nicht Hunde/Nein Hunde/Kein Hunde and compare with Poison plants--> Giftpflanzen--> Nicht Giftpflanzen/Nein Giftpflanzen/Kein Giftpflanzen!Neither of the proposed translations leads to a good German expression. And in other languages it can be even worse! And, as far as I understand, the negated and translated form is expected to be a search input from the user?! One way out of this difficulty would the construction of a second list with translated and negated attribute texts. But again here: the user should have access to all the lists involved here to make use of the proper texts for attributes.

  7. wthaemelt reporter

    Comment to Giftpflanzen:

    Thanks for the idea giving a more or less formal way to describe the negative of an attribute (an even more formal but equivalent way to do this would be "Giftpflanzen (-)"). While I like such more formal approaches, they contradict to a certain degree the concept of a more or less verbal description of a search string. Thus, another but similar approach could be to put the negation not on the right-hand side of the search string (the expression or value) but to add a few new comparison operators for attributes of the form "equals negative of/with negative of/...". Also, an additional keyword "negative of attribute" could be conceivable (here I don't know what can be done with the "and" operator: are "attributes with x and y" or "attributes with x and name without z" feasible search strings. On the answer to this question depends a bit what could be done).

    Comment to shit:

    The implication of this is to declare explicitly that QMS can only handle properly the subset of geocaches that comply strictly with the groundspeak/geocaching.com rules for attributes. Obviously, in the many sources of geocaches there are plenty of geocaches not belonging to this subset (the shit part). The basis for the existence of the shit part is more or less described by the second phrase in

    https://www.cachewiki.de/wiki/Attribute

    Trying to handle in QMS all conceivable ways to describe geocache attributes would certainly be nice. But this goes far beyond the currently implemented approach to handle geocaches. And it would certainly imply to design a completely new concept for attribute handling. Certainly, no one would volunteer to implement this.

    Summary:

    • Restrict complete handling of geocaches in QMS those which follow the geocaching.com rules, especially those for attributes
    • If the users tries to open a geocache in QMS not following these rules, than inform about this fact (put something like "attributes don't comply with rules/Not all attributes comply with rules" in edit/info window and put a special mark on the geocache in the workspace). Maybe, it is even possible to suppress the attributes search in the extended search. What I don't like is to let the user be in the dark: the geocache is there in the workspace and the user doesn't get informed that not all input was handled as expected.
  8. kiozen

    I am not much of a fan of such message boxes and I always regret it when I have done it in the past. We have plenty of these already in the code and they don’t do any good. User do not want to read them nor do they try to understand them. They are simply irritated by them. Some are totally blocked as they do not know how to proceed. And if that shows up several times they get annoyed.

    After all if a source is distributing erroneous GPX files it will go on regardless of what QMS does. And this will make these dialogs popping up again and again. I just had this experience with a flaky GPS tracker and this stupid dialog that was demanded to show up when loading broken tracks. It drives the user of the device nuts. And I had to defend QMS doing so. Which is hard to do if you agree with the annoyed user.

    I am sick of working around other people’s flaky stuff. Of course it is a bug that QMS crashed on a bogus value and fixing it was important. But I do not see much worth in spending much time on a mitigating solution.

  9. wthaemelt reporter

    Ok. Obviously 2 different software development strategies. Each with its pros and cons. And you as head of the whole project made a clear decision. I appreciate this. Thanks for spending time on the discussion.

  10. Log in to comment