V1.1 crashes at end of download (sometimes) #2256
Comments
|
Do you mean "SQL export" by download? There is currently an issue where Sequel Pro crashes when cleaning up the memory from the export.
|
|
Sorry, should have been more clear. These are 'downloads' (not local exports) - ie. downloading a database backup from a remote (live) server down to my local Mac. I have been doing this every evening with SP for several years for several remote databases. The last version (pre-v1.1) was rock solid, it never crashed unless you were trying to open (in my case) more than 4 new SP windows and doing more than 4 simultaneous downloads (remote server to local Mac). So I always kept to a max of 4 download windows at a time. But this crash happens with a single download (remote server to local Mac) - not every time, but it does crash. I did two (separate, not simultaneous) downloads tonight and it crashed on the second one. And the crash seems to be at the end of the download - the downloaded SQL file seems to be complete. Is that clearer? Hopefully so :-) (SP v1.1 is a lot faster now :-) Try a few downloads (remote to local) and see what you get? |
Nope, explain in detail your steps to "download" a database. |
|
Now I'm wondering if I should have bothered reporting this... someone else (probably quite a few people) will be reporting this in the next few days / week / weeks. If you want to be pedantic (?) then yes, the menu selection is 'Export' when you download a copy of the database from a remote server. But (and if you have a Mac yourself you will be familiar with this) 'Exporting' from most Mac apps is saving a copy of what you're working on to your Desktop in a different format. As I said ... this is a downlaod of a database copy from a remote server ... so ...
Select all default options on next window, and also tick 'Auto increment value'.
Rinse and repeat, you'll see SP crash on one of the 'repeats'. Clearer now? Really! :-) |
|
So, you are talking about an SQL Export. A download is essentially a copy operation. Downloading a file means that now the sender AND the receiver will have an exact copy of that file. In essence a download never changes the format of a file. An export however is a conversion of the representation of data (ie. a format) into another format. Export also implies that a loss of information might occur from the conversion. For example: You can export a Photoshop file as a JPG image. This is an export because you lose all information of layers as well as image quality. Or you can export a Pages document as PDF – which will lose the possibility to edit. This is exactly what happens with Sequel Pro! It takes the data that is delivered by mysql in a binary format and converts it into SQL commands. SQL has nothing to do with how the data is actually stored on the server, it is merely an input/output interface. |
|
"There is currently an issue where Sequel Pro crashes when cleaning up the memory from the export. The 'export' settings are the default ones, with the addition od 'Auto increment' - screen shot attached. The data could be changing due to customers browsing the website(s) (the sites are all online shops) but the previous version has never crashed in this way over the last several years using previous versions of SP (same backups). Some more info: Local Mac: Mac Pro 2010, Mavericks, 33GB (c. 6GB used, typically) SP seems to be crashing at the same point: (AutoReleasePool) so you may be right about the memory. For example: Thread 19 Crashed:: Dispatch queue: NSOperationQueue 0x648001437a60 I can't seem to attach the 3 crash reports with this message - either by drag-dropping, or 'Selecting' them - I get the error 'Something went really wrong and we can't process that file. Try again.' So I'll email them to you instead. This is the 'export' settings screenshot: |
|
I can’t attach the crash report logs with my last reply (just now) on Github, so here they are: |
|
Yeah, that is: http://log.sequelpro.com/view/4528 (and others). Do you have Xcode installed or know how to use Terminal? |
|
I don't have Xcode installed. I can copy and paste into Terminal. |
|
OK, then in Terminal run Once Sequel Pro crashes again, there should be some output in Terminal that I need. |
|
I use password auth, so I couldn't run that - otherwise I wouldn't be able to 'export'. This is a cPanel server account (not 'root') so I don't know if I could use a public key - no idea. |
|
You can use the workaround of manually opening the SSH tunnel then. SSH will then ask for your password, which you have to enter manually and press return. Then in Sequel Pro select the favorite, switch its type to "Standard" and Set Host = 127.0.0.1, Port = 12984 and connect (don't save the changes). |
|
Another crash - same place, doesn't crash every time though - last time was last Thursday, today is Wednesday, about 10 databases 'exported' each day. I havn't been able to implement your suggested Terminal code - I would need to do it 10 times each day, maybe when I have more time. |
|
Ooops! - spoke too soon, another crash immediately after the last one - same place again, but this time SP crashed before it had finished 'exporting' the database and the .gz file it created locally couldn't be expanded ('Could not extract file xxxx.sql.gz - the archiive is incomplete'): |
|
Well, the thing is, the crash report is not helpful at all with this bug. |
|
Well, I seem to be able to crash SP pretty reliably 'exporting' with one particular database, at least tonight - 6 crashes in straight succession, but none with other databases - at least, not tonight. On the other hand, your SSH manual login code (above) does not work on a cPanel server where you don't have root - you get a message that SSH 'shell access is not enabled on this account, contact support for assistance'. Then it disconnects you. Port 3784 is used specifically for SSH/SFTP on cPanel servers. So how SP manages to connect with the same criteria via SSH (and it does ... I have screen grabs! :-) and I can't connect via Terminal, I don't know. Perhaps because SP is opening a database connection, not a pure SSH connection? I can also connect via SSH to this server using FTP clients. Any ideas? And with NSZombie running, I can't connect (it seems) at all via password and SP, even using straight (non-secure) connections?? |
In that case add
This should work. I've used this in the past myself. |
|
Ok, it worked this time. Here's the output from the zombie: And the crashed thread (in case you need it to compare) is: And another crash: The thread that crashed: And another one: And another one: And the crashed thread: SP is not crashing every time today - I've 'exported' this same database about 9 times to get these 4 crashes. This database is 3.5MB compressed, 194 tables. I'm wondering if it's this particular database (?) Anything else you need? |
Oh well, I already feared it would be something generic as that. |
|
Yep, no problem - you have my email address to send it (or post a download link). It's not the database - I've just done 6 'exports' in succession (from the same remote server to my local Mac) and SP crashed on #1 and #5. |
|
Any progress on this bug? Do you want me to test a special bug-finder build? I'm still using 1.02 because that's the last version that doesn't crash on me. Not sure how more people are not seeing regular crashes. I'm on the latest Yosemite now. |
|
This issue has been marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
|
This issue has been auto-closed because there hasn't been any activity for at least 21 days. However, we really appreciate your contribution, so thank you for that! 🙏 Also, feel free to open a new issue if you still experience this problem 👍. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Just installed v1.1 tonight.
Just tried some single window downloads (one download at a time) and SP is sometimes crashing as the download completes.
So, SP doesn't always crash when a download completes, but it does sometimes.
Downloads seem complete though - the last table in the database being downloaded is present in the SQL file.
Good point: It's so much faster than the previous version, thanks! :-)
The text was updated successfully, but these errors were encountered: