You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have been using an older nightly fine (7 May or so) but downloaded a recent nightly (24 May) and now if I browse a recently browsed table, DB4S crashes. http://screencast-o-matic.com/watch/cbhZ2HXkz2
Windows doesn't really provide useful info where its crashing, so not sure what helpful info I can provide.
I haven't tried the obvious yet of rebooting and retrying. The problem is fairly reproducable. Haven't tried another database either.
Worthy of note that the database is on a server (with plenty of disk space) but haven't had issues before.
Ignore the 'semi crash' when the program is restarted - it only does that when Avast 'sandboxes' it, so its something to do with DB4S checking for a version update and getting 'nothing' back, or something...
Edit: Just tried a different database on a different machine (so still via a network, but not the same above server) and the same issue - browse a table fine, but browse a previous table and 'BANG'.
Thanks for tracking this down, @chrisjlocke! In this case I believe that this is indeed caused by 7ad8035. I'm just not sure why yet and it will be tricky to debug because it doesn't crash for me. But I'll try 😄
@MKleusberg If it's useful, I can kick off the windows build script and point it at a branch of your repo or something, to make some one off build(s) for Chris to test with.
Ahhh. sqlite.org now lists 3.19.2 as the latest. I've just updated the Win build box with that and kicked off a modified version of the nightlies build script. We should have new binaries for today in ~1/2 hour.
Yeah, makes sense to use the latest SQLite version. But it's probably not the source of the problem here (I guess).
Can you make a build from this branch? This prints some rudimentary debug output to the console.
@chrisjlocke Can you test again using those build? It should still crash but - when you start the new build from cmd.exe - print some debug information that hopefully provides at least some clue on where to start looking for the bug 😉
Also, it crashes when I move away from "Browse Data" tab and re-select it again. I can only select "Browse Data" tab once right after opening any database, and as soon as I select another tab and try to go back to it, DB4S crashes. Nightly versions up to 19 May work fine.
I downloaded the debug version issue1019v1 but it is not printing anything.
C:\Users\Karim\Desktop\DB Browser for SQLite>"DB Browser for SQLite.exe"
C:\Users\Karim\Desktop\DB Browser for SQLite>
Confirmed. Still crashes, and no output is created from running it from the command-line. It might have to explicitly log it to a file? I don't think Windows has a 'console' that applications can write to.
I tried to run it with an output option ('dbrowser for sqlite.exe >log.txt') but that didn't work either.
Cool, thanks 😄 But no worries if you don't have the time for it tomorrow. I think I'll borrow an Windows laptop one of the next days and see if I can spot something.
Thanks to both of you 😄 The Fedora VM is a really good idea, and I'll probably come back to the Windows VM, too, at some point.
But I've just tried the latest nightly on a Windows system without development environment and it just worked. Then I've installed an older one and it crashed. So to me it looks like it's been fixed by one of the last commits 🎆 Not sure though, so maybe you can double check 😉
@MKleusberg Just compiled and tried it (Fedora 25 x64, XFCE version, updated with most recent packages as of today using dnf)... immediate crash upon opening a project file still. Doh! 😉
But I've just tried the latest nightly on a Windows system without development environment and it just worked.
Opening a project file works if you browse the tables first from the database (ie, open the database first). Did you do that? Opening a 'new' project file (ie, not opening the database first) seems to cause the project crash.
Viewing a table in the latest nightly doesn't appear to crash anymore. Should I therefore close this issue, and raise the 'opening a project file crashes' issue instead?
Thanks, Chris! This was it - it seems to depend on the saved active tab in the project file. If it is the Browse Data tab it works, if it isn't it crashes. And of course I always did it the wrong way 😉 But finally I've managed to reproduce this (even on my system) and I think it should be fixed now.
So we had two separate issues. One for browsing the same table again which I guess was fixed by 6984d45, and another for loading certain project files which should be fixed by f4fad4a. Can you again double check it's working for you, too? 😄 Also, as pointed out earlier I think #1007 might have been fixed by the first commit, too. So that's worth testing as well.
Activity
justinclift commentedon May 24, 2017
Interesting. Does the nightly from before 19th May work? eg the 18th or similar.
I'm wondering if it's a side effect from b7cd1c7 somehow. 😄
chrisjlocke commentedon May 24, 2017
I'll have a go tomorrow... certainly ones from early May were OK.
chrisjlocke commentedon May 25, 2017
Yes, nightlies from 18 May and 19 May worked fine. The nightly from 20 May exhibits the above crash.
The culprit has been found.
justinclift commentedon May 25, 2017
Awesome @chrisjlocke. 😄
MKleusberg commentedon May 26, 2017
Thanks for tracking this down, @chrisjlocke! In this case I believe that this is indeed caused by 7ad8035. I'm just not sure why yet and it will be tricky to debug because it doesn't crash for me. But I'll try 😄
justinclift commentedon May 26, 2017
@MKleusberg If it's useful, I can kick off the windows build script and point it at a branch of your repo or something, to make some one off build(s) for Chris to test with.
justinclift commentedon May 26, 2017
Oh... one other thing springs to mind. I recently updated the Windows build box to use SQLite 3.19.0. I wonder if that's the cause?
justinclift commentedon May 26, 2017
Ahhh. sqlite.org now lists 3.19.2 as the latest. I've just updated the Win build box with that and kicked off a modified version of the nightlies build script. We should have new binaries for today in ~1/2 hour.
MKleusberg commentedon May 26, 2017
Yeah, makes sense to use the latest SQLite version. But it's probably not the source of the problem here (I guess).
Can you make a build from this branch? This prints some rudimentary debug output to the console.
justinclift commentedon May 26, 2017
Yep, will do. Gimme a bit. 😄
justinclift commentedon May 26, 2017
k, it's building now. In theory it they should pop up in the *-onceoffs dirs in ~1/2 hour:
... and have "issue1019v1" in their name.
MKleusberg commentedon May 26, 2017
Cool, thanks 😄
@chrisjlocke Can you test again using those build? It should still crash but - when you start the new build from cmd.exe - print some debug information that hopefully provides at least some clue on where to start looking for the bug 😉
karim commentedon Jun 2, 2017
I have the same exact problem as @chrisjlocke.
Also, it crashes when I move away from "Browse Data" tab and re-select it again. I can only select "Browse Data" tab once right after opening any database, and as soon as I select another tab and try to go back to it, DB4S crashes. Nightly versions up to 19 May work fine.
I downloaded the debug version issue1019v1 but it is not printing anything.
chrisjlocke commentedon Jun 2, 2017
Confirmed. Still crashes, and no output is created from running it from the command-line. It might have to explicitly log it to a file? I don't think Windows has a 'console' that applications can write to.
I tried to run it with an output option ('dbrowser for sqlite.exe >log.txt') but that didn't work either.
26 remaining items
justinclift commentedon Jun 21, 2017
k, I'll have another go at it tomorrow, and see if I can collect more useful info for what's going on. 😄
MKleusberg commentedon Jun 21, 2017
Cool, thanks 😄 But no worries if you don't have the time for it tomorrow. I think I'll borrow an Windows laptop one of the next days and see if I can spot something.
justinclift commentedon Jun 21, 2017
Hmmm, maybe run up Fedora 25 x64 (their XFCE download ISO) in a VM, and see if it crashes for you? Might be easier. 😄
chrisjlocke commentedon Jun 22, 2017
If you want a Windows VM, let me know.
MKleusberg commentedon Jun 22, 2017
Thanks to both of you 😄 The Fedora VM is a really good idea, and I'll probably come back to the Windows VM, too, at some point.
But I've just tried the latest nightly on a Windows system without development environment and it just worked. Then I've installed an older one and it crashed. So to me it looks like it's been fixed by one of the last commits 🎆 Not sure though, so maybe you can double check 😉
justinclift commentedon Jun 22, 2017
@MKleusberg Just compiled and tried it (Fedora 25 x64, XFCE version, updated with most recent packages as of today using dnf)... immediate crash upon opening a project file still. Doh! 😉
MKleusberg commentedon Jun 22, 2017
Huh. Nevermind then 😉
chrisjlocke commentedon Jun 23, 2017
Opening a project file works if you browse the tables first from the database (ie, open the database first). Did you do that? Opening a 'new' project file (ie, not opening the database first) seems to cause the project crash.
Viewing a table in the latest nightly doesn't appear to crash anymore. Should I therefore close this issue, and raise the 'opening a project file crashes' issue instead?
Fix possible crash when loading project files
MKleusberg commentedon Jun 26, 2017
Thanks, Chris! This was it - it seems to depend on the saved active tab in the project file. If it is the Browse Data tab it works, if it isn't it crashes. And of course I always did it the wrong way 😉 But finally I've managed to reproduce this (even on my system) and I think it should be fixed now.
So we had two separate issues. One for browsing the same table again which I guess was fixed by 6984d45, and another for loading certain project files which should be fixed by f4fad4a. Can you again double check it's working for you, too? 😄 Also, as pointed out earlier I think #1007 might have been fixed by the first commit, too. So that's worth testing as well.
justinclift commentedon Jun 26, 2017
Awesome! Just tried on OSX... no crash when opening a project file.
I'll jump on the Linux dev box in a bit and try that too, just to make sure as that one was definitely crashing prior. 😄
justinclift commentedon Jun 26, 2017
Yep, the crash-on-opening-project-files is fixed here on Fedora 25 now.
Thanks @MKleusberg. Well done. 😁
chrisjlocke commentedon Jun 27, 2017
Works perfectly. Many thanks @MKleusberg .
MKleusberg commentedon Jun 28, 2017
Thank you for all the testing 👍 I'm glad we finally got there 😉