Bug report #13738

OSGeo4W QGIS dev Windows 32-bit builds crash when the Browser panel is enabled

Added by Steven Mizuno over 8 years ago. Updated over 8 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Browser
Affected QGIS version:master Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:Yes Copied to github as #:21765

Description

This occurs with 32-bit builds from OSGeo4W; also happens when I compile myself, using OSGeo4W configuration.
The standalone QBrowser also crashes.

Win 64-bit builds don't appear to be affected.

running on Windows 8.1 64-bit system and Windows 7 64-bit.

This is after rev. fe6456f that fixed a problem introduced in rev. 70bff3f.
versions affected: 2.13.0-7 rev. commit:f996c4 and 2.13.0-8 rev. d3ee16f; may be others -- not tested.

Note that 2.13.0-3 rev. 3d93237 (before 70bff3f) does not crash.

For some reason (something that flashed by, I think) I had an idea that one or another of the web service providers may be related to this problem, so I removed the various web service provider .dll files and used just the file and database providers. Now QGIS/QBrowser don't crash.

Associated revisions

Revision fe3417b5
Added by Nyall Dawson over 8 years ago

Partial revert of 70bff3f

Commit was causing crashes in browser. Refs #13738

History

#1 Updated by Jürgen Fischer over 8 years ago

406db65 is also related. I suspect there are more QString references passed to threads (via signals?) and dereferenced after the referenced QString object is already gone. Is there a big gain by passing QString references instead of QStrings? They are referencing the same internal string anyway.

#2 Updated by Nyall Dawson over 8 years ago

Ok, I'll partially revert that commit. I was hoping it would help reduce some of qgis' memory usage, as valgrind is showing that qstrings are one of the heaviest memory usage we have.

#3 Updated by Giovanni Manghi over 8 years ago

  • Status changed from Open to Feedback

Can we close this?

#4 Updated by Nyall Dawson over 8 years ago

  • Resolution set to fixed/implemented
  • Status changed from Feedback to Closed

Should be fixed in master. Please reopen if reproducible after fe3417b5

#5 Updated by Steven Mizuno over 8 years ago

Seems to be OK now. Thanks

Also available in: Atom PDF