Version 6.50 Release Candidate 3 Available...

[dexter]

Release Candidate 3 fixes another crash issue and some other fixes. If there are not showstopper issues reported, this may become the final 6.50 release.

Summary:

• Fixed crash when doing simultaneous local searches
• Turned Growl notifications back on, it was disabled for testing and we forgot to re-enable it
• Fixed issue with AutoPAR defaulting to "stop download if unraring".
• Fixed issue clearing the password list.
• Fixed issue where content filter was ignoring the passworded rar filter options.
• Can now multi-select passwords in the Password list for deletion.
• Paused files are no longer included when calculating download time.
• Changed Logging tab socket errors to provide more detailed messages.
• Removed error message from Logging tab when Search retries, was causing undue concern to users.

The download link for Release Candidate 3 is on the Newsbin Beta Page.

Reply to this thread or contact us through the Newsbin Support Form for bug reports or issues with this release.

[Justin42]

There seem to be issues downloading this in Firefox 25 or IE 10. In Firefox, it wants to download "download.php" which if I try to rename it to an exe file tells me it's not for my version of Windows. In IE it just fills the screen with the "binary" code (doesn't actually download). Only Chrome seems to download it correctly. Just FYI... (all on Win 7)

[gkar]

the drive space check is not checking drives other than the drive designated as download in options, and consequently is causing problems.

[dexter]

the drive space check is not checking drives other than the drive designated as download in options, and consequently is causing problems.

Can you be more specific? It should be monitoring the drives designated as the Data drive and the Download drive. They are the two capacities listed in the Status bar at the bottom of Newsbin. If you are manually redirecting downloads to a 3rd drive, like Download to Folder or something, it's not going to check space on that drive. Is this what you are talking about or are you reporting a bug that Newsbin is not monitoring the data and download drives.

[dexter]

There seem to be issues downloading this in Firefox 25 or IE 10. In Firefox, it wants to download "download.php" which if I try to rename it to an exe file tells me it's not for my version of Windows. In IE it just fills the screen with the "binary" code (doesn't actually download). Only Chrome seems to download it correctly. Just FYI... (all on Win 7)

I can't recreate this. It works fine for me on IE10 and Firefox on Win7. Are you doing this in a VM or is there something unique about your system? I wonder if it's some security setting in those browsers or something.

[gkar]

Can you be more specific? It should be monitoring the drives designated as the Data drive and the Download drive. They are the two capacities listed in the Status bar at the bottom of Newsbin. If you are manually redirecting downloads to a 3rd drive, like Download to Folder or something, it's not going to check space on that drive. Is this what you are talking about or are you reporting a bug that Newsbin is not monitoring the data and download drives.

Only having a problem when i'm redirecting to another drive.

[dexter]

Ok, Newsbin doesn't support that. You could make a feature request that it temporarily monitor any drives designated to receive files.

[SnakeByte]

Sometime last night this version of the app crashed. I wasn't running it through a debugger, so I can't give you more information.

All the app was doing was downloading headers every 18 minutes (It was keeping up with the cache).

[dexter]

So far you are the only one reporting this and we are unable to recreate it. We'll note it and keep an eye out for other reports. I don't know of anyone else downloading headers from 2300 groups every 18 minutes (well besides us since we do that to feed our search index). You could back down to just active groups and see if it is more reliable. Out of your 2300 groups, there are only a few hundred that actually have any new posts.

[SnakeByte]

So far you are the only one reporting this and we are unable to recreate it. We'll note it and keep an eye out for other reports. I don't know of anyone else downloading headers from 2300 groups every 18 minutes (well besides us since we do that to feed our search index). You could back down to just active groups and see if it is more reliable. Out of your 2300 groups, there are only a few hundred that actually have any new posts.

Dexter,

Understand that when I post about crashes, it's not to complain. It's to help. If I can help to get the app working better, yay for everyone, right? Besides, shouldn't this app be able to handle downloading headers from newsgroups without crashing? Why should the count matter?

In any event it has crashed again, and this time while running in a debugger. Am I incorrect in thinking that you value this information?

In case you do, here's the details:

Code: Select all

The instruction at 0x14029C8B4 referenced memory at 0xFFFFFFFFFFFFFFFF. The memory could not be read (exc.code c0000005, tid 3696)


I can't give you a stack trace as it's smashed (The instruction at that location of a the crash was retn). Looking at the instructions above the crash location, it looks like I'm in a function with a switch statement that goes through strings like "DNS - Unable to Find Peer Address", and ultimately calls FormatMessage. The crash happened after that function was called. Perhaps some bad parameters were passed to it?

[Quade]

I appreciate you trying to figure out where the problem is.

It suggests stack overflow or heap corruption. I think it might be more fruitful if you could determine which group was being imported at that time with something like "ProcMon". I think the problem is some unexpected data in one of your groups.

[Innuendo]

I can't recreate this. It works fine for me on IE10 and Firefox on Win7. Are you doing this in a VM or is there something unique about your system? I wonder if it's some security setting in those browsers or something.

For what it's worth, I wasn't able to download this or the last release candidate in Firefox. I don't expect you to troubleshoot this, though, as I'm running the latest Firefox 26 beta along with a lot of extensions including FlashGot in tandem with Internet Download Accelerator. A file of 0 bytes is downloaded.

Oh, but...as I was writing this reply I went to Help|About in Firefox to see what version I was running & saw the "Restart to update" button. I did and now the download worked properly. Seems the problem, at least in my case, was a Firefox problem.

TL;DR version: Move along! Nothing to see here!

[SnakeByte]

I appreciate you trying to figure out where the problem is.

It suggests stack overflow or heap corruption. I think it might be more fruitful if you could determine which group was being imported at that time with something like "ProcMon". I think the problem is some unexpected data in one of your groups.

Quade,

It is likely that that is the case, however, I don't think identifying the group is going to help here. Even when I run the app again directly after a crash, it behaves itself, sometimes for many hours (perhaps days). If a single group was responsible, I would expect the app to crash soon after starting again.

I've enabled function tracing in the debugger, so let's see what comes from that. I'm hoping to use that in case the stack is trashed again.

[dexter]

...I don't think identifying the group is going to help here. Even when I run the app again directly after a crash, it behaves itself, sometimes for many hours (perhaps days). If a single group was responsible, I would expect the app to crash soon after starting again.

Having the group may still be helpful. It's possible that when it crashes and you restart Newsbin, it has already ridden through whatever bad stuff in the group made it crash in the first place. You can PM the group to Quade instead of posting it here.

I've enabled function tracing in the debugger, so let's see what comes from that. I'm hoping to use that in case the stack is trashed again.

To be honest those dumps don't really help us. By the time you report something the code has already changed and the offsets are different in Quade's copy. It is more helpful to come up with a procedure that consistently reproduces the problem so we can catch it in the act ourselves.

[SnakeByte]

I've enabled function tracing in the debugger, so let's see what comes from that. I'm hoping to use that in case the stack is trashed again.

To be honest those dumps don't really help us. By the time you report something the code has already changed and the offsets are different in Quade's copy. It is more helpful to come up with a procedure that consistently reproduces the problem so we can catch it in the act ourselves.

As long as we're both using the same binary, the location I report should remain the same since it's just a relative offset. Open it up in a debugger and if you look up the location I post, we'll be looking at the same place. If I had the pdb files however, I could give you exact function names (PDB files don't reveal much more than that, and certainly not source code if you're compiling retail).

This time it crashed at 0x1402A9D39. Here's enough byte code of the binary so that you'll know for certain you're at the right place:

48 89 45 08 48 85 F6 74 27 80 3E 00

(The actual instruction is: CMP BYTE PTR [rsi], 0)

Again no stack.

Note this is the 64-bit version of the program. I'll PM the debug output file that newsbin created. The usernet service is supernews.

[SnakeByte]

Same crash, same place (0x1402A9D39).

Same instruction:

Code: Select all

cmp byte ptr [rsi], 0

rsi = FEEEFEEEFEEEFEEE

since RSI is that value, I'm guessing some memory protection safeguard was put in place to force the crash here, which tells me that the subroutine is attempting to use uninitialized or free'd memory.

All I can tell you is that the code in this subroutine is small. It accepts 4 arguments, calls one win32api (memmove) and then maybe calls another subroutine before returning.

There are almost 40 other places in newsbin's code that runs this subroutine... The subroutine's address is: 1402A9CD0

Again, this crash happened while newsbin was downloading headers. (948 entries at the time of the crash)

the last thing recorded in the debug file was: XOVER alt.binaries.ftn.music 1230024:1230034

It took well over a day of newsbin running before this crash occurred.

[SnakeByte]

Code: Select all

The instruction at 0x14029C8B4 referenced memory at 0xFFFFFFFFFFFFFFFF. The memory could not be read (exc.code c0000005, tid 3696)


I can't give you a stack trace as it's smashed (The instruction at that location of a the crash was retn). Looking at the instructions above the crash location, it looks like I'm in a function with a switch statement that goes through strings like "DNS - Unable to Find Peer Address", and ultimately calls FormatMessage. The crash happened after that function was called. Perhaps some bad parameters were passed to it?

This other crash just happened again. (It looks like I'm experiencing two unrelated crashes)

The function has a simple jump table which chooses which message to send to FormatMessage. In this case, the message was "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond."

There was a null terminator after the message, but maybe the problem was with the lpbuffer, or size parameter passed to FormatMessage. What is clear is that message is what clobbered the stack since the stack pointer is pointing right in the middle of the message.

[gkar]

am seeing deleted watch topics and groups in the NBI that ive deleted that still have counter entries

[Quade]

So, you're thinking that after the delete they're still being used?

[bertm]

If I delete a file from my download list that was captured from my Watch Topics before any part has been downloaded, will it be recaptured for download? I believe this happens to partially complete files that I delete - they seem to "reappear" in my download list once my news server has a complete file set.

Could you tell me what is needed to flag an unwanted file so another download of it will not be attempted.

[gkar]

So, you're thinking that after the delete they're still being used?

As far as I can tell the counter is behaving at it should. Group update sets new files. On group load new files resets to zero. I also see this reflected in the NBI. It when you delete a group/watch topic that the entries are left in NBI and not deleted. On the face if it appears to be a housekeeping situation.

btw would it be possible to have an unread counter?(will post this in feature requests too)

p.s. I see Or'ing is still not working/implemented in watch topics I guess this is on your todo list?

many thanks

[Quade]

Yeah. If it's still being posted, I'm not sure there is a good way. I'll have to think about it. Might better for you to pause it for now, then clean it out after you know the posting is completed.

[csnews124578]

Hi,

before I used Version 6.42. Now with 6.50rc3, there seems to be a change/bug with passworded rars. In 6.42, if I had assigned a Password (without "Add New") this worked. Now, in 6.50rc3, the Password seems to be forgotten when it was not added to the list of Passwords before.

EDIT: Found the "Password retry" thread. Please ignore the quoted text, but think about the focus

One small Suggestion: Can you please set the Focus to the Password box when the window is opened (but keep OK as Default Action).

Thanks for this great product!

Cheers
CS