Steelskin
-
Posts
18 -
Joined
-
Last visited
Posts posted by Steelskin
-
-
14 minutes ago, Rami said:
I'm usually not blessed with some spells and magic , I wish I was Gandalf
Life would be so much better if Gandalf would wave his wand (actually, I don't think Gandalf needed a wand, different story), .... Would wave his wand at Eset and fix NOD32. All would be right in the world. 😊
-
-
1 hour ago, Kirill said:
While their paid licenses with specific expiration dates keep ticking? I don't think there will be any "waiting" only judgement about ESETs responsibilities in regard to their paid products.
Totally agree, I will be requesting a pro-rata refund based on how long it's taking Eset to resolve this.
Currently my feeling is that Eset will not be receiving a renewal. This isn't open source software. We pay you good money for a product and you're not delivering a product that does what it's supposed to do. In fact open source is vastly better because at least users generally get feedback from the developers. Is there any 'official' comment from Eset about this problem and I'm not talking about any moderators comments in this forum.
-
2 hours ago, Marcos said:
Please tell us when you contacted ESET UK and if you received a confirmation email with a ticket ID enclosed.
Sometime in early December 2019. if I remember correctly, I made contact by using the interface in NOD32 for reporting problems. I've no idea where that's reported to, does it even work ? I assumed it was to HQ in Slovakia. I've searched my emails back to 1st December 2019 and have nothing from Eset about a ticket number, just a lot of emails from people reporting the problem on this forum.
-
Despite contacting Eset officially they have so far not responded. I'm not impressed to say the least. On the plus side, I've noticed my laptop feels faster in terms of how fast programs start having deinstalled NOD32. I don't know whether anybody else has experienced this. It's a fairly subtle improvement in speed but a improvement non the less. But then I guess that's to be expected when Eset is not scanning every file that's opened.
-
3 minutes ago, Rami said:
AMD RX 550
And maybe but only maybe that might be the reason. I'm using Nvidia GTX570M.
-
12 minutes ago, Rami said:
Version 79.0.3945.79 (Official Build) Built on Ubuntu , running on Ubuntu 18.04 (64-bit)
Works fine here.
OK Rami, please give us a full description of your hardware, what desktop environment your using graphics card, drivers, whether you have hardware acceleration enabled.
-
2 minutes ago, Miroslav N. said:
I still don't know what is different in my system that is not causing Chromium 79 to crash
It's not necessarily all versions of 79 that have a problem. Early versions of 79 may be fine.
What I would like to see is an official response from Eset acknowleging the problem and a resolution, rather than users having to desperately try to figure it out for themselves.
-
2 hours ago, denixx said:
Could you please at last install Chrome v79+ from Google and stop being amazed?
Also, please follow up the Craig's post here: https://support.google.com/chrome/thread/17555930?hl=en&msgid=22484348
He says:
"Hello everyone,
We’re following up to let you know that we plan to enable the underlying feature (Renderer Code Integrity) that resulted in the previous incompatibilities with the release of Chrome M79 today."
Looks like it's an issue of Chrome from Google.
Not a Chromium one.
Also, I would take your attention to the fact that Chromium != Google Chrome.
Thank you!
Whoever said it's not an issue with Chromium is wrong. It is an identical issue with Chrome & Chromium from the tests I've done. Just depends on what versions you are using.
-
Actuall pkill did not work you have to kill -9 pid on each eset daemon
-
If you run Chrome from the command line while the Eset daemon is running, Chrome produces the following sandbox error.
[5012:1:0109/230249.177870:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[5012:1:0109/230249.178539:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.If you kill the Eset daemon 'sudo pkill esets' then you don't get the above error.
-
On 12/27/2019 at 8:01 PM, Ellis said:
Will a fix be supplied or will Endpoint V7 be provided free to existing customers ?
Or will we all be requesting refunds and the associated bad press that will produce ?
Really ? A bug fix in Q1/2020 and no bug fix planned for the ESET Linux Desktop Home edition ? Seriously ? 😠
-
Quote
As for the home version of ESET NOD32 for Linux Desktop, there are currently no plans for a newer version. If there's some news on this, we'll let you know.
If there is no plan for updating ESET NOD32 for Linux Desktop then my plan will be to request ESET to refund the balance of my three year subscription on multiple licences.
-
It's now the 6th Jan and Chrome is still crashing when the Eset_daemon is running. Does anybody know if anybody is working on this issue ?
-
9 hours ago, Rami said:
It does run fine with me , weird
As you mentioned above, you were running version 78.xxx of chrome. That's why you don't see a problem. You need to be running the following versions of chrome to see this crash with eset running ..
79.0.3945.88-1 (or earlier versions of 79.xxx)
80.0.3987.16-1
81.0.4000.3-1
-
Here is the output of chrome when Esset is running, each crash causes a flash from the browser window. As mentioned, if you kill all esset processes chrome does not produce any of these errors. Perhaps eset is restricting access to some of the mentioned files ?
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc
child_process_sandbox_support_impl_linux.cc
google-chrome
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:48:49-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: 3d06fa8f5af5eccd
0K 516K=0s
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:49:23-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: 5f55aaeec16904a0
0K 701K=0s
[3430:1:1229/164931.173442:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
[3430:1:1229/164931.174160:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:49:34-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... [3430:7:1229/164934.169052:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: 5ed3418cc240f454
0K 530K=0s
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:49:46-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: 422b1aaff8efaf04
0K 608K=0s
2019-12-29 16:49:47 (608 KB/s) - ‘/dev/fd/4’ saved [16]
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:50:03-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
0K Crash dump id: cb0f23b71c235577
752K=0s
2019-12-29 16:50:04 (752 KB/s) - ‘/dev/fd/4’ saved [16]
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:50:30-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
[3548:3548:1229/165030.059220:ERROR:gpu_channel_manager.cc(450)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: f435d6b86734c2ff
0K 525K=0s
2019-12-29 16:50:30 (525 KB/s) - ‘/dev/fd/4’ saved [16]
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:50:42-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
[3600:3600:1229/165042.882151:ERROR:gpu_channel_manager.cc(450)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: deb7fb7dd42968c9
0K 390K=0s
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
--2019-12-29 16:50:57-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
[3618:3618:1229/165057.522014:ERROR:gpu_channel_manager.cc(450)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: f0c2365749e2da02
0K ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure
[3164:3181:1229/165107.283404:FATAL:gpu_data_manager_impl_private.cc(990)] The display compositor is frequently crashing. Goodbye.
--2019-12-29 16:51:07-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... --2019-12-29 16:51:07-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: 831813565f56f112
0K 1.06M=0s
200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: 979b0a24e5d28e5c
0K
521K=0s
2019-12-29 16:51:08 (521 KB/s) - ‘/dev/fd/4’ saved [16]
--2019-12-29 16:51:08-- https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.169.78, 2a00:1450:4009:816::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.169.78|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: 135d2926c153fe7e
0K 506K=0s
2019-12-29 16:51:09 (506 KB/s) - ‘/dev/fd/4’ saved [16]
Illegal instruction
(After this Illegal instruction message the entire chrome browser crashes).
-
Since early December 2019, Chrome and Chromium on Linux crash after a few minutes of use. This problem has been reported in various other forums and it seems that a number of users are experiencing this problem. There appears to be a problem in either Eset or Chrome/Chromium.
I'm running eset anti-virus software and have found that if I kill all eset processes then Chrome stops crashing. In other threads I've seen mention of simply disabling 'real time file protection' but that did not work for me. I've no idea if the problem is in Eset or Chrome (or Chromium, which also has the same problem) and I've found the problem in versions of chrome since 79.0.3945.88-1 and the previous version plus later versions 80.0.3987.16-1 and 81.0.4000.3-1.
Interestingly one of the symptoms is that you see the webpage flash several times as you move about the webpage and after a few minutes Chrome or Chromium crashes. Looking at the console output each flash corresponds with a crash being reported then sometimes prior to the crash an invalid opcode.
As to whether it's a bug in eset or chrome I've no idea at present but killing all running eset processes appears to have stopped Chrome crashing.
This is happening to two different systems, one runs Kubuntu Linux 18.04LTS and the other is KDE Neon (Based on Ubuntu 18.04LTS). The problem started after an update on or around 4th December 2019.
Chrome 79 always starts a core dump and crashes
in ESET NOD32 Antivirus for Linux Desktop
Posted
Any news on a fix for us Linux users who use Chrome, Chromium etc 😕 I see there is no mention on the Eset website. Is it too much to ask of Eset that they actually 'officially' acknowledge that there is a problem and they have a plan of action. I really do detest companies that don't keep their customers in the loop about progress (if any).