Windows 8.1 crashes #122
Comments
|
i have the same on windows 7 64bit. It crashes all the freaking time, sometimes after a couple of seconds of starting it. I'm going insane soon. Problem signature: |
|
Unfortunately I cannot reproduce any of the crashes that are being reported. It might be an Can you both try some of the nightly builds and try to pinpoint which build the problem starts with? We have builds that go all the way back to April 3rd. That'll give us a place to start. |
|
Alright I downloaded the latest nightly (from today) and extracted it in a seperate folder. Does work so far without crashes. I'll keep you updated. |
|
That... makes no sense. You're talking about Unless #118 causes it to crash from queuing up so many skills. Hmm... With the official release, did you notice if it happened when working on your character, or on All 5, or what? Also, were you using the .exe installer, or the zipped file? |
|
It happened to me on any character, All 5 and All 0. i also noticed that sometimes the Resistances/Recharge Rates etc don't change when i switch characters. I'm using the .exe version and will now go through and try the nightly versions. |
|
Can you give reproduction steps to show that stats don't update when switching characters? |
|
Also, if folks can get a video of starting pyfa all the way to it crashing, that would probably help a lot, just so I can replicate 1:1 what you're doing. |
|
Sadly not. All i did was fire up pyfa since it crashed, load up a fit, switch character to all V and back. Last nightly build works for me as well, talking about edit: Also the nightly builds don't crash, checked all of the current version. |
|
edit: new crash message following the "old" crash message: |
|
Same thing is happening to me on 64-bit Windows 7. Recorded a quick video of it happening: I've seen it crash on loading drones (like this one), equipping modules from the market, and selecting and deselecting drones from the drone bay. About to try the nightly builds and see if anything changes. Edit: Most recent nightly still crashes, so going to go back before the recent release and see if I can find a stable one. Edit 2: Looks like the |
|
Thank you guys for participating and help in trying to nail this down. The videos are very helpful. Someone on the forums mentioned that disabling automatic HTML export seems to fix the crashes. I don't have automatic export enabled on my test install which might be why I cannot reproduce, and I'm not currently home. Can you please try to disable this option on your installations and report back? The option is in Window > Preferences > HTML Export EDIT: |
|
With automatic HTML export and running pyfa from source, I was able to get a few exceptions (long traceback included). When pyfa did crash, dump file states that "exception was raised when thread tried to read from or write to a virtual address for which it does not have the appropriate access." |
|
Yeah, looks like disabling html export on the current release fixed the crashing on mine. It's a good workaround until we figure out what the problem is. |
|
A little background on how the automatic HTML works: You change a fit, it has a 1 second delay to handle "quick fitting" so that it doesn't start to run immediately after adding a module. Then it starts to process. This process can take a few seconds on large fit databases. If you change a fit again while it's still processing, it sends a flag to tell it to stop processing the current process and start over. This helps with timing and keeping the load on the database down. I believe this is part of the reason for this crash. When we are looping through the fits, we must check to see if the stop flag has been set in the middle of the loop and, if so, exit out. However, there are a few loops in the HTML export code, and we need to be careful about where exactly we put this check. I think the crash happens when we try to change a fit at the same time as the export is trying to handle it, causing conflicts. Removing the 1 second delay causes these errors to pop up all the time when trying to fit things in quick succession. The quickest, simplest fix would simply be to shove the entire bit of code into a |
|
This may solve the issue, if it's related to HTML export. Too bad my first video failed, but i had pyfa crash on me right after i loaded a fit without changing anything. I'll try to reproduce it and get a video of it. |
|
So, pyfa has a Every time you add or remove a module/charge, this event fires. The fucntion that responds to this event also starts the automatic HTML export if enabled. However, simply opening a fit also fires this event as a shortcut to calc the fit and update the stats. So I find it entirely possible that it crashed after simply opening the fit. |
|
Whelp, still getting the crash. Different exception: And more: |
|
I think I found the problem commit via bisect: fbc336b The automatic HTML export doesn't necessarily cause the issue, rather it allows the issue to manifest. Seems the issue might stem from the porting of the import/export features from EOS to the service layer. Since this is a somewhat hard problem to reproduce (can sometimes go 2-3 minutes of refitting without hitting it), I'm not 100% confident of the problematic commit, but it is somewhere to start |
|
Can you guys try something? In the pyfa directory, open up Please keep in mind proper indentation otherwise python will have a fit. Then open Obviously make sure automatic HTML export is enabled (please enable then close and reopen pyfa, otherwise the setting will not save if pyfa crashes). Then please see if you can reproduce. This seems to work for me, but I'd like confirmation from others. |
|
Works fine for me so far (after i figured out you used space and not tabs :)) |
|
Same here. |
|
Excellent. I'll commit this fix and get ready for another release then. |
|
I'd like to thank you for your fast and excellent support, keep up the good work! |
|
My pleasure. I want pyfa to not crash as much as the next guy 😄 I'd like to thank you guys for going the extra mile with videos and local code changes upon my request. Really proved helpful. As for the cause of this crash, and this is a best guess, but I think it stems from the HTML export thread trying to modify a location in memory that is controlled by the main thread. When I moved the import / export functions from the backend "eos" to the service layer, I must have allowed these two threads to cross using the same data - probably the fit object that it's trying to export. Threading is confusing and I've never really dealt with it much. But hopefully this fixes things. |
Problemereignisname: APPCRASH
Anwendungsname: pyfa.exe
Anwendungsversion: 0.0.0.0
Anwendungszeitstempel: 49180193
Fehlermodulname: sqlite3.dll
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 4c30323e
Ausnahmecode: c0000005
Ausnahmeoffset: 0003a2cd
Betriebsystemversion: 6.3.9600.2.0.0.256.4
Gebietsschema-ID: 1031
Zusatzinformation 1: 5861
Zusatzinformation 2: 5861822e1919d7c014bbb064c64908b2
Zusatzinformation 3: d1d9
Zusatzinformation 4: d1d94a13d3609d6b740644c12508f581
Happen like every 5 minutes when i'm messing around with fits. Doesn't depend on ships, modules, whatever, not reproducable (unless you count continuing to fit stuff as reproducing, but it won't crash on the same module over and over)
The text was updated successfully, but these errors were encountered: