macOS client hangs when downloading corrupt compressed blocklists #4702
Comments
GaryElshaw
changed the title
|
Duplicate of #2272, I think. It's had a |
|
Sadly, no :-( It had been resolved some time ago, but is back. This is a potential blocker. Sucks, i know. |
|
What is the URL of the blocklist that you're using? |
|
What feels like the project default: https://github.com/Naunter/BT_BlockLists |
|
That is not the URL in your screenshot. I'm trying to reproduce the bug; could you please paste the URL that you're using when you encounter this failure 🙏 |
ckerr
added
needs clarification
|
It's not the same? https://github.com/Naunter/BT_BlockLists/raw/master/bt_blocklists.gz |
ckerr
added
confirmed
bug:regression
and removed
needs clarification
|
Confirmed. Seems to require https://github.com/Naunter/BT_BlockLists/raw/master/bt_blocklists works https://github.com/Naunter/BT_BlockLists/raw/master/bt_blocklists.gz hangs forever |
ckerr
changed the title
Ok, I have tried to debug it myself. |
|
I agree we need to improve this process and handle errors more graceful. |
|
@ckerr You can close this one. |
|
@nevack looks like it's hanging when callling |
Yep, I see the same hang on waitUntilExit. I think we should use some lightweight 3rd-party library for working with archives, current implementation (which is my refactor) is a burden :( |
|
As per https://stackoverflow.com/questions/2001709/how-to-check-if-a-unix-tar-gz-file-is-a-valid-file-without-uncompressing |
|
|
|
There are three things. There is the automation/update of the file; how that file is manually updated; but also that the dialog window cannot cancel the process of manually updating. |
Yup, piping to null fixes this hang. |
That's what I tried first via the NSTask output property, but wasn't sure how to get the first filename when doing that...
Agreed! I would love if this was done in core so that it works in non-macOS clients too. Something like KArchive but without the dependency chain... |
Recently we discovered we do not properly handle broken tar archives. The problem is running tar (in linting mode) on invalid archive and piping stdout to NSPipe introduces a hang as NSPipe cannot process such huge data amounts. Fixing this problem by adding a precheck with tar (listing mode) with piping stdout to /dev/null. Fixes: transmission#4702
I decided to run listing twice - with |
|
Yep, WfM too. Thanks for the fast fix @nevack ! 🚀 |
Recently we discovered we do not properly handle broken tar archives. The problem is running tar (in linting mode) on invalid archive and piping stdout to NSPipe introduces a hang as NSPipe cannot process such huge data amounts. Fixing this problem by adding a precheck with tar (listing mode) with piping stdout to /dev/null. Fixes: transmission#4702
ckerr
changed the title
|
@GaryElshaw you're right; this is a blocker. Thanks for reporting this. Also, thanks for persisting when I initially misunderstood the report 👍 |
Recently we discovered we do not properly handle broken tar archives. The problem is running tar (in linting mode) on invalid archive and piping stdout to NSPipe introduces a hang as NSPipe cannot process such huge data amounts. Fixing this problem by adding a precheck with tar (listing mode) with piping stdout to /dev/null. Fixes: #4702
What is the issue?
This bug appears to be back, automated blocklist updating is seemingly not happening, again.
Edit: An added bonus. When manually updating, 'Processing blocklist...' continues into infinity and the cancel button is greyed out.
Which application of Transmission?
macOS app
Which version of Transmission?
4.0.0-beta.3.dev (724a0f4)
The text was updated successfully, but these errors were encountered: