QGIS » QGIS Application

Hi,

I downloaded the Nantucket shapefiles, played around a bit, made a few basic geoprocessing operations and... I cannot replicate (no crashes nor freezes) the problem using qgis 1.0.2/1.2 installed with yhe Osgeo4w installer and windows Vista 32 bit.

Until we cannot replicate the problem in some way, I will change the priority of this ticket.

As for the other tickets you opened I will advice testing the 1.2 version installed with the osgeo4w installer: there were already many bugs fixed in the development release that probably will not be backported in the 1.0.x/1.1 releases. Qgis 1.2 will ship pretty soon.

PS

a recent thread in the grass-user mailing list remembered me (that I'm not used to 64 bit o.s./applications) that using a 32 bit application on 64 bit o.s. can be source of (many) problems. I guess that the available qgis binaries are not optimized for 64 bit windows.

If you compile the source code on 64 bit linux systems, qgis works fine, so you may want to try compile qgis on your machine; is not that easy as under linux but is possible and also documented.

I'm not sure if one set of shapefiles is sufficient to replicate this or not. Also testing on 32bit might indeed hide the bug. Vista 64bit crashes usually can be either random, or they'll sometimes tell you specifically if it was shutdown as part of Vista's Data Execution Protection mechanism (the NX Bit found in all modern 64bit processors).

The issue is also very random. I've been able to use the same QGIS instance for several hours everyday for 3-4 days without issue, and then when you least expect it, the bug will happen. It's only on QGIS-1.1 that it seems to at least generate an actual crash. QGIS-1.0 either crashed, or did the weird graphical "breaking" effect that I described, so it's possible the bug exists somewhere in that component. I'm not sure if you guys are tapping the hardware for any rendering support or not, but in 1.0, once the break happened, it messed the entire screen, taskbar included, up, until you task-switched to another windows application, then everything worked right again, allowing you to terminate QGIS.

I've discovered (the hard way), that any "tricks" used with video memory, like double-buffering in some DivX-based video players on Vista 64bit can cause DEP to fire to kill the program, because DEP feels that is a malicious behavior from a program. The cheap workaround is adding the program to the DEP exception list, usually until the program gets fixed to not require the exception.

Do you guys have any kind of debugging module that can enable logs of some kind for when the program acts up?

Also, try making sure you have the option "Make lines appear less jagged at the expense of some drawing performance", in the options menu on the "Rendering" tab. Since I'm seeing this with line selection, maybe this plays into it.

Hi again,

using qgis 32 bit on vista 32 bit might hide the bug... or not. It would be indeed better to test a version of qgis compiled against 64bit. I'm almost sure that no one of the developers do compile on windows 64 bit, so any effort in this sense would be appreciated.

Until then I would ask you to test qgis on other machines with your usual datasets and see if you can replicate the problem in order to exclude issues with your installation/architecture.

Thanks

Just ran into this again. Interestingly enough, it did not crash this time. I played around in what was left of the interface, and noted a few things:

- Layer window still functions, can be moved around and even closed.
- Print Screen button does not function, and will not copy a screenshot into the clipboard.
- Main map window is completely inoperative when this occurs, minimize/maximize operations do nothing, and the taskbar is muddled until you switch away from the application. If you switch to another app, then attempt to switch back to QGIS, nothing happens. The taskbar button is depressed, but no window updates happen, and graphical drawing artifacts can appear depending on what else you do in the window, however, the map canvas area is able to be "clicked through" to the underlying windows application, which will switch to it at this point.

I was able to trigger this while zoomed into road-level data of Frederick County, MD, using Tigerline datasets. The other visible layers were surrounding counties in MD, WV, and VA (County 2000, Designated Places 2000, and Water polygons), and some custom layers I've created.

The actual trigger was using the select/lasso tool, and I was in the middle of selecting a line element, with rendering on. It was when I released the mouse button, triggering the rendering operation to start to display the color of the selected line, that it occurred. The dotted gray box indicating my selection box remained partially on the screen at this point, but everything else was blanked then.

I'm going to up this back to critical -- I haven't seen data corruption happen at this point, but I can trigger this pretty consistently it seems. It is random, but so far consistent. Should I try the 1.2 nightlies? (Assuming 1.2 is the nightly stuff you've referenced)

Well, my little bulleted list got muddled there. Here's a better copy:

• Layer window still functions, can be moved around and even closed.

• Print Screen button does not function, and will not copy a screenshot into the clipboard.

• Main map window is completely inoperative when this occurs, minimize/maximize operations do nothing, and the taskbar is muddled until you switch away from the application. If you switch to another app, then attempt to switch back to QGIS, nothing happens. The taskbar button is depressed, but no window updates happen, and graphical drawing artifacts can appear depending on what else you do in the window, however, the map canvas area is able to be "clicked through" to the underlying windows application, which will switch to it at this point.

Replying to [comment:6 kumba]:

Should I try the 1.2 nightlies? (Assuming 1.2 is the nightly stuff you've referenced)

Hi,

try install the qgis-dev version (1.2) using the osgeo4w installer

http://trac.osgeo.org/osgeo4w/

Can you please make me a package with all the layers (beside the custom ones) you are using and make it available for download?

For now I'll leave this ticket as critical, but if in the next days no one will replicate the problem I guess we will have at least to change its priority. In any case I (again) will suggest to make tests on other pcs/platforms as it really seems a local problem. Maybe is a problem with win 64 bit environments, but again the actual installers are not optimized for this environment, so I'm not so surprised of what you describes.

If you want you can also compile on your box

http://www.qgis.org/wiki/Installation_Guide

it would be very useful.

I gave a shot at setting up a compile environment, but further inspection reveals that may not solve anything. In addition to getting stuck at libjpeg's compile phase, I realized that the mingw compiler that is installed is gcc configured for "i686", which is gcc's acronym for 32bit x86. It'd need to be an x86_64 target for proper 64bit compiling, and I'm not too keen on trying to battle mingw into that on my Windows platform.

I'll keep plugging away, and if I get an actual crash next time, I'll see if I can get MS to dump crash details somewhere about it.

Murphy is my shadow. Sitting there selecting roads in a layer for Montgomery County, MD, and I thought "I'll bet it'll crash in a minute".

Crashed on the next road selection.

Other noted oddities:

• Bottom status bar appears to still function and update with mouse X/Y coordinates, but it becomes "misplaced", so to speak.
• Remained up for several minutes, but as soon as I started to move the mouse around on the screen, Windows finally crashed it. Problem appears to be in Qt it looks? Text of the crash data is below, but it's not much. Can't work anything out of MS's poor debugging info.

Problem signature:
Problem Event Name: APPCRASH
Application Name: qgis.exe
Application Version: 0.0.0.0
Application Timestamp: 4a020316
Fault Module Name: QtGui4.dll
Fault Module Version: 4.4.3.0
Fault Module Timestamp: 496534b9
Exception Code: 40000015
Exception Offset: 000cbf99
OS Version: 6.0.6002.2.2.0.274.10
Locale ID: 1033
Additional Information 1: 766e
Additional Information 2: 59e27f7a0dd84b22718abe4d6d8eb445
Additional Information 3: 2c74
Additional Information 4: 5cfcea8459f4d4d579b37d7054e1470f

Read our privacy statement:
http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409

I will also attach a picture of my screen that I took with my camera. Print Screen may not function, but Murphy isn't going to stop a camera!

Ah, it seems Trac here dislikes certain kinds of formatting.

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    qgis.exe
  Application Version:    0.0.0.0
  Application Timestamp:    4a020316
  Fault Module Name:    QtGui4.dll
  Fault Module Version:    4.4.3.0
  Fault Module Timestamp:    496534b9
  Exception Code:    40000015
  Exception Offset:    000cbf99
  OS Version:    6.0.6002.2.2.0.274.10
  Locale ID:    1033
  Additional Information 1:    766e
  Additional Information 2:    59e27f7a0dd84b22718abe4d6d8eb445
  Additional Information 3:    2c74
  Additional Information 4:    5cfcea8459f4d4d579b37d7054e1470f

Read our privacy statement:
  http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409

Now in the attached photo, it's hard to see exactly (because Windows "fades" a crashed application until you kill it), but you can see a line feature highlighted a shade of purple -- that's the road I had just selected in Montgomery County, MD's roads layer (from Tigerline). When I went to select the next section, which is just northwest of the selected section of that same road (it's the much lighter blue color), that's when the graphical "glitch" happened, and crashed a few seconds later after I tried fiddling in the GUI some.

Replying to [comment:9 kumba]:

In addition to getting stuck at libjpeg's compile phase,

Hi,

you may want to ask in the dev mailing list

I realized that the mingw compiler that is installed is gcc configured for "i686", which is gcc's acronym for 32bit x86. It'd need to be an x86_64 target for proper 64bit compiling, and I'm not too keen on trying to battle mingw into that on my Windows platform.

this may help?

http://sourceforge.net/projects/mingw-w64/

Eh, I can't say I wholly agree with closing it and marking as invalid, but I understand the reasoning. If Trac has it, something more like Bugzilla's "RESOLVED::LATER" fits better, as I imagine that in time, someone on the qgis development team will acquire a 64bit Vista, Server 2008, or Win7 install/platform and be able to release a few packages for them after some experimenting.

However, I'll try 1.2 out and see what it does. 1.2 didn't work the last time I tried it (1.2.0-4 I think in the OSGeo4W installer?), as it was unable to load some kind of DLL on startup. This appears to be fixed in 1.2.0-12.

Hi

I'll try 1.2 out and see what it does. 1.2 didn't work the last time I tried it (1.2.0-4 I think in the OSGeo4W installer?), as it was unable to load some kind of DLL on startup. This appears to be fixed in 1.2.0-12.

Please do. And then let us know if it works or not.