Webroot failed to update its threat definition. This likely means your device doesn't currently have internet access. You can continue your scan with the current definition set or cancel. Error: OutOfMemoryError processing def update. Continue or Cancel.
Also, DEFINITION UPDATE FAILED. Network error attempting to access the Webroot servers. Please ensure your device is connected to the Internet.
Also, Webroot Secure Anywhere Mobile Premier (process com.webroot.securing full) has stopped unexpectedly. Please try again.
DEFINITION SET 330. Version 2.9.0.3559.
Is somebody know what to do??? The HELP recommended to post on FORUM to get E-mail from MODERATOR to send collected system data from phone for tech support. Or may be it would be solved by itself??? For example, via updates?? But how come, the updates fail to be installed?
Page 5 / 7
I'm getting this same error message everytime I turn on my phone and run a scan. My phone is only 5 months old (Razor Maxx) and I don't play any games and have downloaded less than 5 apps. Its pretty frustrating that this error hasn't been resolved in the months since it has been initially identified. I wasn't always getting the error on my phone, but in the last couple of weeks, it does not resolve when I run a scan. I found webroot to be problematic on my pc and laptop before I upgraded when I purchased my smart phone in June (the program would not autoscan). But I saw the reviews for Secure Anywhere and bought into a 3 year, 5 product plan. I have 4G service and I have also connected to my wifi at home and the problem still exists. Having spent a lot of time on previous software errors, sending multiple logs and still getting no resolution until the "new product release" was introduced doesn't have me that hopeful that this error will be solved.
@ jimbo & Jaxx
I fully understand your frustration. Shouldn't I have my sentiment for WSA and shouldn't I have believed in Webroot capabilities to resolve this problem I would have already swapped WSA Android for another AV solution.
I think the main problem is that Webroot is complaining for insufficient RAM but WSA itself is the glutton in fact. In my case WSA eats around 70 MB of RAM whereas all other applications doesn't exceed more than 12 MB but majority of them is around 5-6 MB. So it easily explains why I am not getting the OOM error once WSA is terminated and restarted, i.e. RAM is freed up.
Yes it is annoying to terminate and restart WSA to let allow the proper definition sets updates but please give them at Webroot a chance to troubleshoot this issue. I trust Roloc and other folks are doing their best to get over this problem as soonest.
I fully understand your frustration. Shouldn't I have my sentiment for WSA and shouldn't I have believed in Webroot capabilities to resolve this problem I would have already swapped WSA Android for another AV solution.
I think the main problem is that Webroot is complaining for insufficient RAM but WSA itself is the glutton in fact. In my case WSA eats around 70 MB of RAM whereas all other applications doesn't exceed more than 12 MB but majority of them is around 5-6 MB. So it easily explains why I am not getting the OOM error once WSA is terminated and restarted, i.e. RAM is freed up.
Yes it is annoying to terminate and restart WSA to let allow the proper definition sets updates but please give them at Webroot a chance to troubleshoot this issue. I trust Roloc and other folks are doing their best to get over this problem as soonest.
pegas:
Yes it is annoying to terminate and restart WSA to let allow the proper definition sets updates
- I've tried to force update after WSA has been terminated and get the same problem.
but please give them at Webroot a chance
- they've had 8 weeks
Yes it is annoying to terminate and restart WSA to let allow the proper definition sets updates
- I've tried to force update after WSA has been terminated and get the same problem.
but please give them at Webroot a chance
- they've had 8 weeks
@ wrote:
pegas:
Yes it is annoying to terminate and restart WSA to let allow the proper definition sets updates
- I've tried to force update after WSA has been terminated and get the same problem.
but please give them at Webroot a chance
- they've had 8 weeks
Hmmm, it seems that it is much worse in your case than in mine and yes 8 weeks is too much. There are no excuses for such a long time to resolve this fundamental hitch but I decided to give them a grace period to show WSA is worth to stay on my HTC.
I'm glad you are so optimistic. But I can tell you from past experience, sending logs and doing "work-arounds" and months later the problem persists. I have no doubt they are working on the problem, but my phone isn't the problem. I'm certain there are many others with the problem who like me assumed it was a recent glitch that would be fixed quickly. But when I look up and see that the problem has been on-going for 2 months, leads me to think that its not likely to be fixed until a new product comes out and I get a complimentary upgrade. But meanwhile, I feel that my phone is vulnerable and I paid for a product that isn't performing as expected. I tried the forced update too as suggested - doesn't work. So meanwhile, I'm dissatisfied with a product that I just paid for a 3 year subscription to. As far as I know, it performs as expected/intended on my PC and Laptop as I haven't gotten any errors.
I think a detailed, technical explanation is in order. While we can't fix this issue for everyone, you deserve the best explanation as to why that we can muster. Fair warning: this may put you to sleep, but if you're curious enough to be on here asking why this longstanding issue isn't fixed for the small subset of our users still seeing it happening, you will probably want a good answer to your question. So here goes.
RAM Management in Linux/Android
As I had mentioned before, on a PC, you have virtual memory that serves as sort of a "backup" to your physical memory. And I had mentioned that this sort of fail-over doesn't exist on Android devices. Well, it's worse than that. Android works more like Linux in terms of RAM management, in that there is really no such thing as "free" memory until the operating system declares that memory to be free. On Linux/Android systems, all memory is always in use at all times. Theoretically, and usually in practice, that means your memory is optimized for faster distribution. On Linux, that works wonderfully most of the time. On Android, well, it's kind of hit-and-miss.
Garbage, Collector
It's so hit-and-miss that the process that controls memory allocation was actually replaced wholesale by certain device manufacturers (Samsung, notably), who realized early on how buggy that original process is. The process is called "Garbage Collector," (though it could just as easily be called Garbage - The Collector) and it's relied upon by everything running on your device. Problems were observed with Garbage Collector, dating back to the earliest versions of Android. It's actually been rewritten three times since 2.1, and it still doesn't really work right all the time. Suffice to say though, the older your version of Android, the older your Garbage Collector, and the more likely you are to run into OutOfMemory issues.
The trash man is saying the truck is full when it really isn't, so maybe it's time to look at a new trash collection service. Where would one find a newer trash collection service? In this case, in an upgraded OS.
The best way to deal with this, if your device will support a newer version of Android, would be to upgrade your OS, or if your provider won't allow you to do that (and that's squarely on them, as Garbage Collector has been rewritten multiple times due to known bugs), perhaps it's time to look at a new device. I know that's not something anyone wants to hear, but it's inevitable that eventually, with any technology, that's going to happen.
Where do we go from here?
So, if you're getting this error message, in short, you're running into a bug - the proximal cause of which is the Garbage Collector in the OS itself. All Webroot can do is call on the function that should work and hope it works like it's supposed to. If it doesn't work, it's due to what are, in fact, known issues in the Android OS itself. Webroot can only do so much to code around an OS defect. Limiting the size of our footprint is always a top priority, and the most recent changes to the definitions managed to help with this kind of problem in most cases. Amazingly, we cut the "out of memory" errors down from a sizeable amount to what I'm reading as a total of about 5 reports now, combined from here, support interactions, and the bug reports the apps themselves generate. What we unfortunately cannot do is rewrite an OS service, because that is locked down by Android itself. The only solution for some people will be to upgrade your OS. For people who can't do that, it's either time for a new device, or you can wait to see if we come up with another way to shrink the program, or unfortunately, perhaps Webroot is not for you. I'm sorry to be the bearer of bad news, but that's the word from development.
RAM Management in Linux/Android
As I had mentioned before, on a PC, you have virtual memory that serves as sort of a "backup" to your physical memory. And I had mentioned that this sort of fail-over doesn't exist on Android devices. Well, it's worse than that. Android works more like Linux in terms of RAM management, in that there is really no such thing as "free" memory until the operating system declares that memory to be free. On Linux/Android systems, all memory is always in use at all times. Theoretically, and usually in practice, that means your memory is optimized for faster distribution. On Linux, that works wonderfully most of the time. On Android, well, it's kind of hit-and-miss.
Garbage, Collector
It's so hit-and-miss that the process that controls memory allocation was actually replaced wholesale by certain device manufacturers (Samsung, notably), who realized early on how buggy that original process is. The process is called "Garbage Collector," (though it could just as easily be called Garbage - The Collector) and it's relied upon by everything running on your device. Problems were observed with Garbage Collector, dating back to the earliest versions of Android. It's actually been rewritten three times since 2.1, and it still doesn't really work right all the time. Suffice to say though, the older your version of Android, the older your Garbage Collector, and the more likely you are to run into OutOfMemory issues.
The trash man is saying the truck is full when it really isn't, so maybe it's time to look at a new trash collection service. Where would one find a newer trash collection service? In this case, in an upgraded OS.
The best way to deal with this, if your device will support a newer version of Android, would be to upgrade your OS, or if your provider won't allow you to do that (and that's squarely on them, as Garbage Collector has been rewritten multiple times due to known bugs), perhaps it's time to look at a new device. I know that's not something anyone wants to hear, but it's inevitable that eventually, with any technology, that's going to happen.
Where do we go from here?
So, if you're getting this error message, in short, you're running into a bug - the proximal cause of which is the Garbage Collector in the OS itself. All Webroot can do is call on the function that should work and hope it works like it's supposed to. If it doesn't work, it's due to what are, in fact, known issues in the Android OS itself. Webroot can only do so much to code around an OS defect. Limiting the size of our footprint is always a top priority, and the most recent changes to the definitions managed to help with this kind of problem in most cases. Amazingly, we cut the "out of memory" errors down from a sizeable amount to what I'm reading as a total of about 5 reports now, combined from here, support interactions, and the bug reports the apps themselves generate. What we unfortunately cannot do is rewrite an OS service, because that is locked down by Android itself. The only solution for some people will be to upgrade your OS. For people who can't do that, it's either time for a new device, or you can wait to see if we come up with another way to shrink the program, or unfortunately, perhaps Webroot is not for you. I'm sorry to be the bearer of bad news, but that's the word from development.
Jim M-I have read part of this same response on a earlier page, but none of what you stated applies to my situation. I don't own a Samsung - I have a Droid Razor Maxx that I bought 6/3/2012 and has been updated to ICECREAM OS. I have Verizon wireless service also. I use my phone for texting/calls and email and rarely run any apps - maybe Pandora, but certainly not on start-up. I delete my emails and texts daily and rarely have saved anything - including pictures. Yet I still get the definitions update error. I would like a personal response but if that isn't possible, I will open a ticket with Webroot - but as I stated, I haven't been impressed with the response from a previous error that was never fixed until I upgraded to Secure Anywhere. I just upgraded to this Webroot product in June when I got the phone. If this isn't going to work on my phone then I want a REFUND and I will purchase something else for my phone.
Hi Jaxx,
I'm sorry for the confusion. If you read my response just a bit closer, you'll notice that what I'm saying is that Samsung replaced the Garbage Collector with one that works better on their devices. So no, I realize you don't own a Samsung, or you likely wouldn't be reporting the problem at all (though it's possible the same issue could occur I suppose).
I'm also not trying to imply that this issue wouldn't ever exist on a more modern OS. It's just less likely to exist. You can still be either using all your memory and legitimately be getting the out of memory error, or the java garbage collector may still be malfunctioning even on a more modern OS. Ultimately, regardless of the fact that this error is appearing when a Webroot app is running, the error isn't even being thrown by Webroot - it's coming from the OS itself when the OS fails to function as designed.
What you are running as an on-screen app vs. what runs in the background (like in push notifications for instance), are different things. To check what's actually running, you can go to Settings -> Applications -> Running Services. Facebook, for instance, on my own device is set to generate push notifications, and it takes up 46MB just doing that alone.
The memory we are talking about is like RAM on your computer and has to do with how much can be going on on your device at any given time. It has nothing to do with storage space, which on a PC, would be referred to as hard drive space, which is the kind of memory you're referring to when you're talking about pictures. That is a different kind of memory.
If you would like to open a ticket, you are welcome to do so, but the response provided is coming straight from development. Support will not have a different response for you. If you wish to make a case for receiving a refund, a ticket through support would be the route to take in this case. I can't say for sure what the outcome of such a request would be, as I personally have no control over the refund process. Typically, refunds are not processed beyond 70 days, and you've indicated your purchase is over 70 days old.
It's certainly not your fault that you're getting an OutOfMemory error on your device, but it realistically isn't Webroot's fault either that a buggy Java subroutine in the Android OS isn't handling a request properly, thus generating an error. It's a lousy situation, and I feel your pain. I'm going to research what else we can do for you in light of your situation, and I'll follow up with you directly.
I'm sorry for the confusion. If you read my response just a bit closer, you'll notice that what I'm saying is that Samsung replaced the Garbage Collector with one that works better on their devices. So no, I realize you don't own a Samsung, or you likely wouldn't be reporting the problem at all (though it's possible the same issue could occur I suppose).
I'm also not trying to imply that this issue wouldn't ever exist on a more modern OS. It's just less likely to exist. You can still be either using all your memory and legitimately be getting the out of memory error, or the java garbage collector may still be malfunctioning even on a more modern OS. Ultimately, regardless of the fact that this error is appearing when a Webroot app is running, the error isn't even being thrown by Webroot - it's coming from the OS itself when the OS fails to function as designed.
What you are running as an on-screen app vs. what runs in the background (like in push notifications for instance), are different things. To check what's actually running, you can go to Settings -> Applications -> Running Services. Facebook, for instance, on my own device is set to generate push notifications, and it takes up 46MB just doing that alone.
The memory we are talking about is like RAM on your computer and has to do with how much can be going on on your device at any given time. It has nothing to do with storage space, which on a PC, would be referred to as hard drive space, which is the kind of memory you're referring to when you're talking about pictures. That is a different kind of memory.
If you would like to open a ticket, you are welcome to do so, but the response provided is coming straight from development. Support will not have a different response for you. If you wish to make a case for receiving a refund, a ticket through support would be the route to take in this case. I can't say for sure what the outcome of such a request would be, as I personally have no control over the refund process. Typically, refunds are not processed beyond 70 days, and you've indicated your purchase is over 70 days old.
It's certainly not your fault that you're getting an OutOfMemory error on your device, but it realistically isn't Webroot's fault either that a buggy Java subroutine in the Android OS isn't handling a request properly, thus generating an error. It's a lousy situation, and I feel your pain. I'm going to research what else we can do for you in light of your situation, and I'll follow up with you directly.
JimM - I don't use Facebook or other social media on my phone. When I look at how much is running at any time it is less than 25% of available RAM. I'm not sure I understand this comment "but it realistically isn't Webroot's fault either that a buggy Java subroutine in the Android OS isn't handling a request properly, thus generating an error" If this is the case, wouldn't there be lots of Motorola phone users with this problem? I find this very unsatisfactory as a phone less than 6 months old is throwing an OOMemory error when I don't run anything. I appreciate the response, but I'm baffled that using my phone as a mobile email device is causes this type of problem after only 5 months. When my PC was less than 6 months old I had a "non-fixable issue" also and went 2 years doing a manual workaround until purchasing what I stupidly thought was a better product. In this case, there is no "workaround". I have used Webroot products for at least 10 years and at this point 2 strikes on 2 devices that were effectively brand new on a new licensed product. If the product isn't updating properly and I can't control the OS "issues" and its not a Webroot problem and little hope going forward that it will get fixed am I suppose to continue using a anti-virus product that can't update properly and just leave myself vulnerable to a virus? I bought the most expensive plan and I didn't even load all of the licenses but if I have to purchase a competitor product that works just for my phone I will, but I don't think I should continue to pay for a product that doesn't operate properly and can't be resolve either.
It occurs to me that one thing that hasn't been mentioned yet here anywhere in this thread is that you could try running a third-party memory manager app. While those tend to be a mixed bag in terms of effectiveness, it wouldn't hurt to try. I hear good things about this one, and it's free. If one of those kinds of apps helps anyone in this thread, please share any good news.
Jaxx, it appears you replied without reading the private message I sent you. Please check your private messages. There is a little mail icon under the search box towards the top right side of the screen when you are signed in. Please read the message there and reply to it, so I can attempt to assist you as best as possible with the given situation.
Not all of your Webroot for Android features don't work. Backup & Sync, SecureWeb, Wipe, Scream, Lock, and Locate don't rely on definitions updates, so those should all still be working for you. The antivirus portion of the Android protection does not, and possibly may never, work properly on your particular device. That would bother me too, but even if it was my own device or one of the developers' devices, it's not something we can fix immediately or perhaps ever fix, for reasons outlined in prior posts.
To answer your question about the frequency of OutOfMemory errors across the board, yes, this actually is a relatively common issue across various programs. Try Googling "OutOfMemory Android," and you'll see a big list of threads on various forums that call out this issue. A great deal of them are from frustrated developers on dev forums, lamenting how their workarounds don't seem to solve all of the problems. Here and there, you'll see threads that appear to have been resolved, just like how our fix solved the problem for the vast majority of our users. Other places, you'll see developers running into the brick walls of Android OS limitations or users with OutOfMemory issues that never got fixed.
What does work in your particular case is the entire PC product, 3/4 of the Android protection, and all of the Mac protection if you have a Mac. If you've been with us for 10 years, you'll know there was a time when we didn't have Android protection at all, and you were still a customer then. Perhaps a combination of Webroot on your PC and something else on your Android would work out for you (again, please see my private message for more detail on this). If not, and you ultimately decide to leave Webroot, that's unfortunate and we'll be sorry to see you go. Sadly, there isn't anything we can do in the short term to convince you otherwise, beyond pointing out what I mentioned above.
Nobody likes "bad news" posts, myself included. If there was something development could do about this issue quickly for the remaining affected customers, it would be happening. You have my sympathy for your frustration. :( And of course, if development does manage to find a way to get around this issue for the remaining customers that are reporting it, either myself or one of the developers will be sure to update this thread.
Jaxx, it appears you replied without reading the private message I sent you. Please check your private messages. There is a little mail icon under the search box towards the top right side of the screen when you are signed in. Please read the message there and reply to it, so I can attempt to assist you as best as possible with the given situation.
If I was in your position, as one of the handful of remaining affected customers, for which there is possibly no workaround, I would evalutate my options in terms of whether or not the PC protection is worth having on its own - Android protection aside.@ wrote:
If the product isn't updating properly and I can't control the OS "issues" and its not a Webroot problem and little hope going forward that it will get fixed am I suppose to continue using a anti-virus product that can't update properly and just leave myself vulnerable to a virus? I bought the most expensive plan and I didn't even load all of the licenses but if I have to purchase a competitor product that works just for my phone I will, but I don't think I should continue to pay for a product that doesn't operate properly and can't be resolve either.
Not all of your Webroot for Android features don't work. Backup & Sync, SecureWeb, Wipe, Scream, Lock, and Locate don't rely on definitions updates, so those should all still be working for you. The antivirus portion of the Android protection does not, and possibly may never, work properly on your particular device. That would bother me too, but even if it was my own device or one of the developers' devices, it's not something we can fix immediately or perhaps ever fix, for reasons outlined in prior posts.
To answer your question about the frequency of OutOfMemory errors across the board, yes, this actually is a relatively common issue across various programs. Try Googling "OutOfMemory Android," and you'll see a big list of threads on various forums that call out this issue. A great deal of them are from frustrated developers on dev forums, lamenting how their workarounds don't seem to solve all of the problems. Here and there, you'll see threads that appear to have been resolved, just like how our fix solved the problem for the vast majority of our users. Other places, you'll see developers running into the brick walls of Android OS limitations or users with OutOfMemory issues that never got fixed.
What does work in your particular case is the entire PC product, 3/4 of the Android protection, and all of the Mac protection if you have a Mac. If you've been with us for 10 years, you'll know there was a time when we didn't have Android protection at all, and you were still a customer then. Perhaps a combination of Webroot on your PC and something else on your Android would work out for you (again, please see my private message for more detail on this). If not, and you ultimately decide to leave Webroot, that's unfortunate and we'll be sorry to see you go. Sadly, there isn't anything we can do in the short term to convince you otherwise, beyond pointing out what I mentioned above.
Nobody likes "bad news" posts, myself included. If there was something development could do about this issue quickly for the remaining affected customers, it would be happening. You have my sympathy for your frustration. :( And of course, if development does manage to find a way to get around this issue for the remaining customers that are reporting it, either myself or one of the developers will be sure to update this thread.
Hello Jim,
Nice reading, you have shared tons of technical background information about Android and WSA, thanks for your effort. However I can conclude that in no of your post there is a plain explanation why other Android security solutions, and believe me I have tested more than 10 others, never have had this OOM error, at least not on my HTC. So, are they more smart as far as AV definitons deployment is concerned?
Thanks & regards,
pegas
Nice reading, you have shared tons of technical background information about Android and WSA, thanks for your effort. However I can conclude that in no of your post there is a plain explanation why other Android security solutions, and believe me I have tested more than 10 others, never have had this OOM error, at least not on my HTC. So, are they more smart as far as AV definitons deployment is concerned?
Thanks & regards,
pegas
Furthermore, RAM or virtual RAM or whatever else you call it is the issue therefore Webroot should correct System Requirements for WSA Android on their webpage. Users should be aware that even if they have 6 month old device WSA might not be working in the full potential.
Pegas, that's a good question. Unfortunately, I don't have the privilege of their source code to dig through to answer it, but I'd suspect that they are removing definitions they judge to no longer be "worth" having - probably for infections that are not seen as often, or maybe the most complex ones. Doing that would benefit a small subset of users and hurt everyone else. It's not an option we are willing to pursue, because while it would "look" good, it would realistically be quite bad. It's certainly possible there are other ways they worked around this kind of problem, and that's why we're still investigating other possible solutions.
The issue of placing a system requirement on the page for memory usage was something I initially agreed with you about when it was suggested a few pages back. That was before talking to our developers about why this issue isn't fixed for every last customer. Since the root of the issue is that the Android OS itself refuses to free up memory, when by all rights, it should be freeing up that memory, placing a value as a memory requirement would be misleading and arbitrary to anyone experiencing this particular issue. If we did specify a particular value, odds are, you, Jimbo, Jaxx, et. al, would report back "But I meet that value! This should be working!" And you would be right - you probably do meet that value. But again, the core of the problem is not that we are actually exceeding available memory. The core of the problem is that there is free memory to be had, and the operating system isn't handing it over to us as it should.
The issue of placing a system requirement on the page for memory usage was something I initially agreed with you about when it was suggested a few pages back. That was before talking to our developers about why this issue isn't fixed for every last customer. Since the root of the issue is that the Android OS itself refuses to free up memory, when by all rights, it should be freeing up that memory, placing a value as a memory requirement would be misleading and arbitrary to anyone experiencing this particular issue. If we did specify a particular value, odds are, you, Jimbo, Jaxx, et. al, would report back "But I meet that value! This should be working!" And you would be right - you probably do meet that value. But again, the core of the problem is not that we are actually exceeding available memory. The core of the problem is that there is free memory to be had, and the operating system isn't handing it over to us as it should.
That's exactly right Jim. You can get an OOM error while having 100mb free if the garbage collector can not keep up with your requests.
So it is not a matter of requirements.
My wife has a Droid Razr MAXX and webroot runs fine on it, so it is just some combo of apps installed or running and/or the version of the Garbage Collector that are still having the issue.
So it is not a matter of requirements.
My wife has a Droid Razr MAXX and webroot runs fine on it, so it is just some combo of apps installed or running and/or the version of the Garbage Collector that are still having the issue.
I left WSA for another product a while ago, just after all this started and I'm now certain I was right to do so for my own sake. The other product has as good a reputation as the Webroot product and it updates reliably. So if memory management is the same for all Android applications which, of course, it is then I would have to assume that the product I am using is designed and coded differently to avoid such issues or, as you indicate, its developers are limiting the size of its threat register to avoid them by shedding some low risk definitions.
If it is not shedding threat definitions and is dealing with the same range of threats as WSA, then it looks like it has managed the memory issue in a way that has eluded Webroot so far. So far as I understand it,all these security products rely on having a register against which to check for threats and, it seems to me, as the number of threats grows these registers are going to have to grow as well. It could well end up as a race between these registers and the amount of system memory installed (and its management). Sooner or later, a brick wall is going to be hit because memory can't be infinite while the number of threats could be in comparison.
WSA and its competing security products are, I guess, sooner or later going to have to undergo a root and branch re-think and re-design to minimise the dependence on an ever growing register/database of risk defintitions. They are going to have to work differently. Don't ask me how, I have not idea but it does seem to me to be an impending issue. At the same time, it also seems that Android itself could do with a massive security overhaul.
If it is not shedding threat definitions and is dealing with the same range of threats as WSA, then it looks like it has managed the memory issue in a way that has eluded Webroot so far. So far as I understand it,all these security products rely on having a register against which to check for threats and, it seems to me, as the number of threats grows these registers are going to have to grow as well. It could well end up as a race between these registers and the amount of system memory installed (and its management). Sooner or later, a brick wall is going to be hit because memory can't be infinite while the number of threats could be in comparison.
WSA and its competing security products are, I guess, sooner or later going to have to undergo a root and branch re-think and re-design to minimise the dependence on an ever growing register/database of risk defintitions. They are going to have to work differently. Don't ask me how, I have not idea but it does seem to me to be an impending issue. At the same time, it also seems that Android itself could do with a massive security overhaul.
We are most definatly NOT shedding definitions for size. Jim gave a detailed explination a couple of posts back that it appears you may not have read. It may help you better understand the differences between our windows and our android product.
Also I would like to add we are working on this still. We are not giving up. We have had 5 bug reports over the past week to week and a half and that is one of the lowest of all the issues our users see. We have hundreds of thousands of users so making a change specifically to address that low percantage of issues that could dramatically degrade performance for the rest is something we need to balance and not rush.
Like Jim I don't like writting these kinds of posts. I fully understand you guys are frustrated and we are to. We have even more fixes that are going into our 3.1 release.
Steve
Also I would like to add we are working on this still. We are not giving up. We have had 5 bug reports over the past week to week and a half and that is one of the lowest of all the issues our users see. We have hundreds of thousands of users so making a change specifically to address that low percantage of issues that could dramatically degrade performance for the rest is something we need to balance and not rush.
Like Jim I don't like writting these kinds of posts. I fully understand you guys are frustrated and we are to. We have even more fixes that are going into our 3.1 release.
You can rest assured that that process started a couple of months ago and is ongoing. Some of those changes went out in the last release some are coming in the next release and even more are planned for the future releases.@ wrote:WSA and its competing security products are, I guess, sooner or later going to have to undergo a root and branch re-think and re-design to minimise the dependence on an ever growing register/database of risk defintitions. They are going to have to work differently. Don't ask me how, I have not idea but it does seem to me to be an impending issue. At the same time, it also seems that Android itself could do with a massive security overhaul.
Steve
I've uninstalled WSA from my phone and installed another provider. My experience of webroot has not been positive. While I believe that the developers etc are struggling to find a fix, me the consumer has been messed around. Being given the expectation that a fix is imminent only to find time after time that nothing has changed is frustrating to put it mildly. The reality is that I haven't changed my phone or operating system for 10months while WSA worked. I didn't have lots of apps working in the background. So something in WSA changed that led to the problems. Coupled with the fact that other apps work fine suggest that WSA is the problem. Having paid for this app, this is a poor experience. Even if I'm one of the very very few that still have problems...
We're sorry to see you go Jimbo. 😞 If a potential solution becomes available for the remaining affected users, we'll be sure to update this thread. In the meantime, you'd certainly want to have some protection on your device, so it make sense to do what you're doing for now. We'll continue to do everything we can to try to work around this issue. Just because it's affecting a small number of users doesn't mean we've given up on trying to solve the problem, but waiting for a fix in an unprotected state is inadvisable. So, you're doing the right thing for now. Hopefully we'll have some better news next time we post in this thread.
OK, after having monitored behaviour of WSA for a few days on my HTC in relation to definition updates and the OOM error I can draw the following conclusions.
The OOM error occures once a new definition set is released. It means that if there are let's say 2 days before another new definition set is out I am not getting the OOM error. I can check updates manually thousand times and no error observed. However when a new definition set is available I always am getting the OOM error. So it is the sign for me that a new AV definition has been released. So I have to go to Applications Manager and terminate WSA. After that I have to open WSA what triggers WSA to restart. Immediately after restart the orange exclamation jumps out and the definition set is always 373. Afterwards I have to run updates manually what successfuly loads the latest available definition set (today it is 391). Since then I don't have the OOM errors (when checking updates) until a new definition set is released. It is 100% reproducible issue on my end.
Then I have to do all this procedure again to get the latest AV set what makes me indeed mad. This time is tough for me as I am full of temptations to throw out WSA in favour of Avast mobile. Nevertheless later, after having back the green status and a cup of coffee I am fine. I keep WSA yet on my phone thanks to my immense loyalty to Webroot but you, at Webroot, don't rely that this will last forever.
I hope that the above detailed explanation how the OOM error reigns over my HTC will help Webroot techies & developers (Jim & Roloc) to resolve this nasty bug and yes it is a bug regardless what you say.
The OOM error occures once a new definition set is released. It means that if there are let's say 2 days before another new definition set is out I am not getting the OOM error. I can check updates manually thousand times and no error observed. However when a new definition set is available I always am getting the OOM error. So it is the sign for me that a new AV definition has been released. So I have to go to Applications Manager and terminate WSA. After that I have to open WSA what triggers WSA to restart. Immediately after restart the orange exclamation jumps out and the definition set is always 373. Afterwards I have to run updates manually what successfuly loads the latest available definition set (today it is 391). Since then I don't have the OOM errors (when checking updates) until a new definition set is released. It is 100% reproducible issue on my end.
Then I have to do all this procedure again to get the latest AV set what makes me indeed mad. This time is tough for me as I am full of temptations to throw out WSA in favour of Avast mobile. Nevertheless later, after having back the green status and a cup of coffee I am fine. I keep WSA yet on my phone thanks to my immense loyalty to Webroot but you, at Webroot, don't rely that this will last forever.
I hope that the above detailed explanation how the OOM error reigns over my HTC will help Webroot techies & developers (Jim & Roloc) to resolve this nasty bug and yes it is a bug regardless what you say.
The story continues ...
Yesterday WSA auto updated to AV set 391. It was the first time when it was done automatically without necessity to undergo terrifying terminating/restarting procedure stated in my above post. However today WSA automatically checked for updates (observed notification Last checked for definition update on 22.11.2012 at 7:50) and reverted definition set to 373. It seems that this AV set plays an important role in this OOM error issue. I have checked the web console and again there was last definition update before 42 years. Funny thing, indeed. So then I manually run update and received AV set 393 what is now correctly recorded in the console.
Sorry for bothering with my posts in this thread but I want to give Webroot staff as many information as possible. On the other hand I would appreciate Webroot breaks its silence and begins to again communicate via this thread or PM.
Yesterday WSA auto updated to AV set 391. It was the first time when it was done automatically without necessity to undergo terrifying terminating/restarting procedure stated in my above post. However today WSA automatically checked for updates (observed notification Last checked for definition update on 22.11.2012 at 7:50) and reverted definition set to 373. It seems that this AV set plays an important role in this OOM error issue. I have checked the web console and again there was last definition update before 42 years. Funny thing, indeed. So then I manually run update and received AV set 393 what is now correctly recorded in the console.
Sorry for bothering with my posts in this thread but I want to give Webroot staff as many information as possible. On the other hand I would appreciate Webroot breaks its silence and begins to again communicate via this thread or PM.
Update!
There will be improvements in version 3.1 that may help to address the remainder of the OutOfMemory issues still being experienced. 3.1 should be available soon, but we don't have an exact date since Google still has to go through their QA process. Roloc or I will reply back again when it's out. 🙂
There will be improvements in version 3.1 that may help to address the remainder of the OutOfMemory issues still being experienced. 3.1 should be available soon, but we don't have an exact date since Google still has to go through their QA process. Roloc or I will reply back again when it's out. 🙂
Thanks Jim for the update. Eagerly awaiting 3.1 build that hopefully will resolve the OOM error.@ wrote:
Update!
There will be improvements in version 3.1 that may help to address the remainder of the OutOfMemory issues still being experienced. 3.1 should be available soon, but we don't have an exact date since Google still has to go through their QA process. Roloc or I will reply back again when it's out. :)
Build 3.1.0.4541 has been issued today. Have upgraded and there are really really promising signs on my HTC the OOM error could be resolved for good. I will test this build extensively and will revert with results later on.@ wrote:
Update!
There will be improvements in version 3.1 that may help to address the remainder of the OutOfMemory issues still being experienced. 3.1 should be available soon, but we don't have an exact date since Google still has to go through their QA process. Roloc or I will reply back again when it's out. :)
Thanks Jim, Roloc and others of Webroot for your hard work to beat this error.
Stay tuned ;)
Thanks a ton for the update Pegas. We had some funkiness on some of the devices yesterday that wasn't related to OOM issues so we couldn't reply the update was out just yet.
I am anxious to hear how it is going after a few days of use in the field.
Steve
I am anxious to hear how it is going after a few days of use in the field.
Steve
@ wrote:
Build 3.1.0.4541 has been issued today. Have upgraded and there are really really promising signs on my HTC the OOM error could be resolved for good. I will test this build extensively and will revert with results later on.I am very pleased to inform that the OOM error was resolved :D
Thanks Jim, Roloc and others of Webroot for your hard work to beat this error.
Stay tuned ;)
I underwent an extensive testing of the latest 3.1 build on my HTC focusing on the definition set updates which were malfunctioning due to the OOM error. I was playing with the date & time, I was shifting them back and forth to see if AV definitions will be automatically installed or the error will be occuring again. I have got satisfying results ... AV definitions were installed successfuly and no more errors appeared. After that I reverted the date & time back to the actual and waited for updates as per the set schedule which resulted in receiving AV set 400 yesterday and AV set 401 today.
Therefore I dared to proclaim the OOM error was defeated :D
I want to express my thanks to all at Webroot who contributed to resolve this issue. Well done ;)
Furthermore, I want to encourage all users who were plagued with the OOM error to share their experience with the latest 3.1 build.
Thanks & regards,
pegas
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.