Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on project open when mapcanvas extents = nan #35899

Closed
signature-story opened this issue Apr 21, 2020 · 8 comments
Closed

Crash on project open when mapcanvas extents = nan #35899

signature-story opened this issue Apr 21, 2020 · 8 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Crash/Data Corruption Feedback Waiting on the submitter for answers High Priority Project stale Uh oh! Seems this work is abandoned, and the PR is about to close.

Comments

@signature-story
Copy link

signature-story commented Apr 21, 2020

If somehow a project's mapcanvas extents are all erroneously set to nan, then when that project is opened QGIS 3.10.2 will crash. Opening the qgs file in a text editor and changing the extents to realistic numbers will allow the project to be opened and subsequently saved and reopened without issue. But without the user savvy to edit the qgs file, there is no way to recover the project.

Reproduce by creating a new project and then saving as a qgs file. Open that qgs file in a text editor and change all mapcanvas extents to nan like this:
<mapcanvas name="theMapCanvas" annotationsVisible="1"> <units>feet</units> <extent> <xmin>nan</xmin> <ymin>nan</ymin> <xmax>nan</xmax> <ymax>nan</ymax> </extent>

Save the file and then try to open it in QGIS. It will crash.

Then open in a text editor and correct the mapcanvas extents to anything realistic. For example:
<mapcanvas name="theMapCanvas" annotationsVisible="1"> <units>feet</units> <extent> <xmin>0</xmin> <ymin>0</ymin> <xmax>1</xmax> <ymax>1</ymax> </extent>

Save the changes, and you should now be able to open the project in QGIS.

A separate issue is how the extents were erroneously set to nan in the first place. That's more difficult for me to verify and report, but basically it occurred when I tried to zoom to view a feature. That feature may have had bad geometries. Not sure. But it locked the viewing area and would not let me pan or zoom. I was able to exit the project, but when re-opening it would crash. Eventually discovered in the extents set to nan in the project file. If I figure out how to reproduce consistently I'll post a separate report with shapefiles.

QGIS version
3.10.2-A Coruña
QGIS code revision
d4cd3cf
Compiled against Qt
5.11.2
Running against Qt
5.11.2
Compiled against GDAL/OGR
3.0.3
Running against GDAL/OGR
3.0.3
Compiled against GEOS
3.8.0-CAPI-1.13.1
Running against GEOS
3.8.0-CAPI-1.13.1
Compiled against SQLite
3.29.0
Running against SQLite
3.29.0
PostgreSQL Client Version
11.5
SpatiaLite Version
4.3.0
QWT Version
6.1.3
QScintilla2 Version
2.10.8
Compiled against PROJ
6.3.0
Running against PROJ
Rel. 6.3.0, January 1st, 2020
OS Version
Windows 7 SP 1 (6.1)
Active python plugins
LAStools;
profiletool;
shapetools;
db_manager;
MetaSearch;
processing

@signature-story signature-story added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Apr 21, 2020
@elpaso
Copy link
Contributor

elpaso commented Apr 23, 2020

@signature-story can you attach a crashing project? I tried to replace extent with nan on one o my test projects but it didn't crash.

@elpaso elpaso added the Feedback Waiting on the submitter for answers label Apr 23, 2020
@signature-story
Copy link
Author

Zipped qgs file attached. Crashes for me every time. I created it using the steps outlined in the original post: editing new qgs file in text editor to replace extents with nan.

iCrash.zip

@roya0045
Copy link
Contributor

@signature-story if you update your qgis is the crash still occuring?

@signature-story
Copy link
Author

yes after updating to 3.10.5 the crashes continue to occur.

@pblottiere
Copy link
Member

I succeeded in opening the iCrash.qgs project with QGIS master. No crash here on Archlinux.

@gioman gioman removed the Feedback Waiting on the submitter for answers label Aug 2, 2020
@Pedro-Murteira
Copy link

@signature-story I'm not being able to reproduce this issue on QGIS 3.22.5 and 3.24.1. Can you still reproduce the issue in more recent releases?

@Pedro-Murteira Pedro-Murteira added the Feedback Waiting on the submitter for answers label Mar 22, 2022
@github-actions
Copy link

github-actions bot commented Apr 6, 2022

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale".
If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue.
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue.
If there is no further activity on this issue, it will be closed in a week.

@github-actions github-actions bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Apr 6, 2022
@github-actions
Copy link

github-actions bot commented May 4, 2022

While we hate to see this happen, this issue has been automatically closed because it has not had any activity in the last 42 days despite being marked as feedback. If this issue should be reconsidered, please follow the guidelines in the previous comment and reopen this issue.
Or, if you have any further questions, there are also further support channels that can help you.

@github-actions github-actions bot closed this as completed May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Crash/Data Corruption Feedback Waiting on the submitter for answers High Priority Project stale Uh oh! Seems this work is abandoned, and the PR is about to close.
Projects
None yet
Development

No branches or pull requests

6 participants