Closed Bug 1604218 Opened 5 years ago Closed 4 years ago

frequent "dead tabs" when opening a new tab due to content process startup freezes

Categories

(Core :: DOM: Content Processes, defect, P5)

Product:
Core
Component:
DOM: Content Processes
Version:
71 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: n.marti, Unassigned)

References

Details

Attachments

(6 files)

open new tab, type link, progress dot is gray, not loaded after 10min, no consolie output 2019-12-16 15-16-45.png
66.06 KB, image/png
Details
open new tab, type link, progress dot is gray, not loaded after 10min, no consolie output 2019-12-16 15-01-43.png
71.28 KB, image/png
Details
console-output-dead-tab.txt
2.17 KB, text/plain
Details
about-support-mozilla-build.txt
22.29 KB, text/plain
Details
about-support-ubuntu-build.txt
25.48 KB, text/plain
Details
tab_error.png
10.45 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

I have what seem to be 2 separate "dead tab" issues. However, both are intermittent and I haven't found a controlled way to always reproduce them:

  • I open a new tab in a new firefox profile (no addons) by clicking on the "+" in the tab bar; I type a link and hit [Enter]; or
  • less thoroughly documented: I "triple click" a link (on a touchpad) to open it in a new tab (haven't tried a new profile with no addons yet)

The network connection is fine; e.g. I can usually just open another tab and it will work as expected (sometimes I have to open a new instance of firefox, however).

Version Details:
Name Firefox
Version 71.0
Build ID 20191205184924
User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
OS Linux 4.15.0-1065-oem

Actual results:

Case 1:
The little grey progress dot goes back and forth but for at least 10 minutes there is no actual sign of the page getting loaded; e.g. no "Waiting for example.com" or "Performing TLS handshake..." at the bottom, no text or images appear; the page remains white and blank. There is also no output in the browser console (Ctrl+Shift+J).
Both attached screenshots are examples of this case.

Case 2:
The tab opens with the page title in the tab itself, but the page is blank and there is no grey progress dot. I'll reply back if I can capture more details on this one.

Expected results:

In either case the new tab should begin loading the web page immediately, but this is not happening.

Flags: needinfo?(gijskruitbosch+bugs)

If you enable the pref browser.sessionstore.debug in about:config, and reproduce this again, does more output show up in the browser console?

Also, if you open the toplevel menubar in the Firefox window with "alt", are the menus intact, or are e.g. menuitems in Tools ("Outils", I think?) missing?

Also, does Firefox normally restore your tabs when you start? In the screenshots, there's a (3) badge on the Firefox task bar - does this mean there is another window (in addition to the visible browser window and the browser console) and if so, did something load correctly in that window?

Finally, is this a distro build or an official mozilla.org build? If the former, can you reproduce in the latter?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(n.marti)

(In reply to :Gijs (he/him) from comment #2)

If you enable the pref browser.sessionstore.debug in about:config, and reproduce this again, does more output show up in the browser console?

I've enabled this as you suggest, and there is still zero output in the browser console in this particular situation.

Also, if you open the toplevel menubar in the Firefox window with "alt", are the menus intact, or are e.g. menuitems in Tools ("Outils", I think?) missing?

All the entries in Tools/Outils are there.

Also, does Firefox normally restore your tabs when you start? In the screenshots, there's a (3) badge on the Firefox task bar - does this mean there is another window (in addition to the visible browser window and the browser console) and if so, did something load correctly in that window?

It looks like Firefox normally restores tabs from the previous session, but possibly not when one of the tabs is "dead". Since I'm responding in

Firefox, I can't test this right away. But I will soon.

Finally, is this a distro build or an official mozilla.org build? If the former, can you reproduce in the latter?

This is a distro build of Firefox (71.0+build5-0ubuntu0.18.04.1). I can try to install the mozilla version soon.

(In reply to :Gijs (he/him) from comment #2)

Also, does Firefox normally restore your tabs when you start? In the screenshots, there's a (3) badge on the Firefox task bar - does this mean there is another window (in addition to the visible browser window and the browser console) and if so, did something load correctly in that window?

It looks like FIrefox doesn't usually automatically restore the tabs when I reopen it. However it does when I choose "Restore Previous Session" from the menu, except that if a tab was "dead" in the closed session it remains "dead" in the restored one.

There was a Firefox window open in my normal profile. It frequently has the same problem, but I was testing from a separate profile to rule out addons causing the problem. At that particular moment there were no "dead tabs" in the normal profile, and it was working as expected.

Also, opening Firefox just now and trying to go to this page, the tab wasn't loading (i.e. it was "dead"). I tried to open the browser console at that moment with Ctrl+Shift+J and it didn't open. Only after opening a 2nd tab that wasn't "dead" did the keyboard shortcut work to open the browser console. But this only required opening a new tab, not restarting Firefox.

Flags: needinfo?(n.marti)

More troubleshooting in dead tabs: non-exhaustive summary of keyboard shortcuts that work and those that don't.
I didn't try every possible shortcut for various reasons, but maybe this list is helpful anyway.

These shortcuts work when a "dead tab" is in focus:

Alt
Ctrl+N
Ctrl+P
Ctrl+Q
Ctrl+T
Ctrl+W/F4
Ctrl+PgUp/PgDn
Ctrl+Shift+P
Ctrl+Shift+PgUp/PgDn

These shortcuts don't:

Alt+Home
Ctrl+F5 / Ctrl+Shift+R
Ctrl++/-/0
Ctrl+B
Ctrl+F
Ctrl+H
Ctrl+O
Ctrl+R / F5
Ctrl+S
Ctrl+Shift+A
Ctrl+Shift+H
Ctrl+Shift+J
Ctrl+Shift+O
Ctrl+Shift+Y
Esc
F11
Shift+F10

It'd be useful to see if you can reproduce with the official build. Otherwise, if you start the build from the commandline, do any errors appear in stderr/stdout when the tab fails to load? My suspicion is that we're somehow failing to launch the child process, but I'm not 100% sure how I'd verify that. It's also very odd that the browser console is empty...

Flags: needinfo?(n.marti)

(In reply to n.marti from comment #5)

More troubleshooting in dead tabs: non-exhaustive summary of keyboard shortcuts that work and those that don't.
I didn't try every possible shortcut for various reasons, but maybe this list is helpful anyway.

Yeah, the working shortcuts are the ones that we don't allow web pages to override. Anything that's supposed to go to the content process / website is getting lost somehow...

(In reply to :Gijs (he/him) from comment #6)

It'd be useful to see if you can reproduce with the official build. Otherwise, if you start the build from the commandline, do any errors appear in stderr/stdout when the tab fails to load? My suspicion is that we're somehow failing to launch the child process, but I'm not 100% sure how I'd verify that. It's also very odd that the browser console is empty...

To clarify about the empty browser console: I was deleting the output before each attempt to open a new tab to avoid having to scan through a bunch of unrelated output. Maybe that was a mistake, but that's why it's completely empty in the screenshots.

I have previously launched Firefox from the command line to see if there are any errors, just as you suggest, and there was no output there until I closed Firefox completely.

I've now tried with the mozilla build in a VM, and after opening about 30 or so tabs I can't recreate the problem. So that does seem to indicate that the problem is specific to the Ubuntu build.

Flags: needinfo?(n.marti)

(In reply to n.marti from comment #8)

(In reply to :Gijs (he/him) from comment #6)
I've now tried with the mozilla build in a VM, and after opening about 30 or so tabs I can't recreate the problem. So that does seem to indicate that the problem is specific to the Ubuntu build.

Do the VM and your main system have the same version of Ubuntu and the same window manager? Any other software differences that could explain this - is the main Ubuntu build a snap build, for instance, or do you have other sandboxing/hardening tools installed? Can you attach the contents of about:support in both the main ubuntu build (in a clean profile) and the working official build in the VM to this bug?

To be clear, it's quite possible that this is indeed related to the Ubuntu build. But AFAIK they mostly disable the Mozilla crash reporter and not much else. So I'm a bit surprised an effect like this would be caused by just that difference - trying it in a VM (though I do understand why you would want to do it that way - not criticizing, just pointing out that that influences the test) might also change other factors that could cause a problem like this.

Flags: needinfo?(n.marti)
Flags: needinfo?(n.marti)

(In reply to :Gijs (he/him) from comment #9)

(In reply to n.marti from comment #8)

(In reply to :Gijs (he/him) from comment #6)
I've now tried with the mozilla build in a VM, and after opening about 30 or so tabs I can't recreate the problem. So that does seem to indicate that the problem is specific to the Ubuntu build.

Do the VM and your main system have the same version of Ubuntu and the same window manager? Any other software differences that could explain this - is the main Ubuntu build a snap build, for instance, or do you have other sandboxing/hardening tools installed? Can you attach the contents of about:support in both the main ubuntu build (in a clean profile) and the working official build in the VM to this bug?

Ah, that's a good point. My host uses Cinnamon while the VM is stock Ubuntu using Gnome. Both are 18.04 with the stock deb packages.

I've now installed the Mozilla build straight into my host under a different name. Running the Mozilla build in my host gave me the dead tab problem on the 3rd tab opened, and then again on the 5th. I'm attaching the "about:support" contents for both cases, but now it seems the Mozilla build is behaving the same way as the Ubuntu build. I'm also attaching the complete browser console output for the Mozilla build window.

Here's another clue: It seems when a new tab is opened and it turns out to be a "dead tab", there is a new process simultaneously started called "IPC Launch #1" with the same command as the original browser process. Let me explain:
I installed the Mozilla build under ~/firefox-broken-tabs/firefox/, created a profile called "ffmoz", and launched it with
$HOME/firefox-broken-tabs/firefox/firefox -P ffmoz
I also relaunched the Ubuntu build with my default profile.
After having encountered 2 "dead tabs" in the Mozilla build, I checked gnome-system-monitor and noticed 2 processes called "IPC Launch #1", both having the same command $HOME/firefox-broken-tabs/firefox/firefox -P ffmoz.
At this point there was no "IPC Launch #1" process with the Ubuntu build command /usr/lib/firefox/firefox -new-window.
Then I opened another tab in the Ubuntu build window, which turned out to be a "dead tab", and at that point there was a "IPC Launch #1" process with a command of /usr/lib/firefox/firefox -new-window.

These "IPC Launch #1" processes are orphaned; that is, they don't exit when the tab or even the browser window is closed. They have to be killed manually. Each one uses from 100MB to 250MB of RAM, so their toll on the system can really add up if there are very many of them. I had noticed them previously, but I hadn't connected them with this dead tab issue until now.

If I open a tab that turns out to be "dead", and then if I kill the associated "IPC Launch #1" process, the "Tab has crashed" content appears in the "dead tab". I just submitted a report there with this explanation, as well.

(In reply to n.marti from comment #14)

If I open a tab that turns out to be "dead", and then if I kill the associated "IPC Launch #1" process, the "Tab has crashed" content appears in the "dead tab". I just submitted a report there with this explanation, as well.

I forgot to add terminal output from the above situation:

[Parent 20976, Gecko_IOThread] WARNING: pipe error (182): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
[Parent 20976, Gecko_IOThread] WARNING: pipe error (164): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
[Parent 20976, Gecko_IOThread] WARNING: pipe error (109): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
[Parent 20976, Gecko_IOThread] WARNING: pipe error (59): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358

Thanks for all the debugging info! I'm more of a frontend person, and I'm not sure how to dig deeper into the IPC / content process launch failures. I'm going to move the bug to a component related to that, as that seems to be where the issue is, and hopefully folks there can look at this in more detail.

:gcp, can you help gather more information here to clear up why the content process may fail to start, and/or what we can do to detect this has happened in the parent so there's some user feedback? Unsure if this is related to sandboxing specifically or something else...

Component: Untriaged → IPC
Flags: needinfo?(gpascutto)
Product: Firefox → Core
Summary: frequent "dead tabs" when opening a new tab → frequent "dead tabs" when opening a new tab due to content process startup freezes

This isn't an IPC failure. You're getting an IPC error because (as you have determined), Firefox's content process fails to launch or dies quickly, so IPC can't connect to the content process and/or its connection dies.

We have an issue tracking that this error (sometimes) isn't properly reported up the chain: https://bugzilla.mozilla.org/show_bug.cgi?id=1488990 but obviously even if someone would get around to fixing that, that wouldn't fix the underlying issue: the process is crashing for a reason we don't understand, but likely early in startup.

It's somewhat similar to the bug linked from there: https://bugzilla.mozilla.org/show_bug.cgi?id=1471124

the "Tab has crashed" content appears in the "dead tab". I just submitted a report there with this explanation, as well.

Just to check: do you mean you have an actual crash report that corresponds to this hang? Could you link it?

Component: IPC → DOM: Content Processes
Flags: needinfo?(gpascutto)

If there's no crash report it's going to be hard to get anything useful: the problem is that the process crashes (likely) before we can even set up crash reporting. Barring an ability to find a reproducible scenario (or a user who could do a debug build and attach a debugger...), about the only thing I could come up with is a try build with a sprinkling of printfs through the various startup phases?

Further info about the "IPC Launch #1" process:
This orphaned process actually appears to be launched after successfully loading a tab. It's then the next new tab that fails to load anything, but not subsequent tabs.

I started watching gnome-system-monitor before and after opening new tabs, expecting to see "IPC Launch #1" show up just after opening a new dead tab. However, when it does show up, it's actually just after opening a "good tab", but then the next new tab ends up being "dead". If I kill this process as soon as it appears but before opening another new tab, then I don't have the "dead tab" problem. If I don't kill this process, then next new tab opened is "dead". If I kill the process at that point, then the tab displays the "crashed tab" error page.

Bug 1488990 shouldn't apply here, because this is Unix and we should be notified if/when the process exits and closes the socket (see the second paragraph of bug 1488990 comment #0); the error messages in comment #15 are presumably the result of that.

However, there are more layers above IPC, and I've heard from people who work on the DOM side of things that it's not very good about handling failures, so that's where the blank tabs are probably coming from.

As for the process named IPC Launch #1, that would be the chroot helper process for the sandbox; it's cloned from the child process before exec and also doesn't call exec itself, so it inherits the name of the thread that launched it (from a thread pool named IPC Launch). That should also exit if the real child process exits early. (Also I filed bug 1604834 about the name.)

My best guess is that the chroot helper is doing something that's not async signal safe and trying to take a lock that was held by some other thread in the original parent process when it cloned the child; the child process would then block waiting for the chroot server when it tries to start sandboxing.

Bug 1471124 might be related, but in that case it seemed that the main child process got stuck before exec and the chroot server was simply blocked waiting for it, so it might be a different cause.

(In reply to n.marti from comment #19)

This orphaned process actually appears to be launched after successfully loading a tab. It's then the next new tab that fails to load anything, but not subsequent tabs.

That makes sense — we'll pre-launch a content process when the browser is idle, to reduce the time it takes to load the next new tab. So if that locks up, then.

(In reply to Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧ from comment #20)

Bug 1488990 shouldn't apply here

That's not quite right. It applies on all platforms if the child process freezes early in startup; if it crashes or exits instead, then it's only a problem on Windows.

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)

Need a priority set for this one.

Flags: needinfo?(jmathies) → needinfo?(gpascutto)

This sounds fairly serious but there's nothing actionable right now besides bug 1488990 unless we can get a repro on a developers' system.

Flags: needinfo?(gpascutto)
Priority: -- → P5

Have the same bug.
It started only after I installed Nod32.
Ubuntu 18.04
Mozilla 72.0.2 (64-bit)

I too have ESET Nod32 installed. I've just turned off real-time protection to see if the problem goes away. I'll report back in a day or so. I'm now running 72.0.1, still with cinnamon-desktop and ubuntu 18.04.

(In reply to n.marti from comment #26)

I too have ESET Nod32 installed. I've just turned off real-time protection to see if the problem goes away. I'll report back in a day or so. I'm now running 72.0.1, still with cinnamon-desktop and ubuntu 18.04.

So, with ESET Nod32 installed but with "Real-time file system protection" disabled, I still got a dead tab after opening about 7-10 of them. It's not clear to me if there's a simple way to keep Nod32 from running without uninstalling it, and unfortunately, since I'm working from a production laptop, I'm not able to uninstall Nod32 right now.

I have also dead tabs from half a year (difrent Firefox versions) and i had instaled NOD32 also.

Mozilla Firefox 72.0.2 (64 bit)
Ubuntu 18.04.2
ESET NOD32 4.0.93.0

Start of dead tabs could be corelated in time with NOD32 instalation.
I'll try to investigate it further.

(In reply to n.marti from comment #27)

(In reply to n.marti from comment #26)

I too have ESET Nod32 installed. I've just turned off real-time protection to see if the problem goes away. I'll report back in a day or so. I'm now running 72.0.1, still with cinnamon-desktop and ubuntu 18.04.

So, with ESET Nod32 installed but with "Real-time file system protection" disabled, I still got a dead tab after opening about 7-10 of them. It's not clear to me if there's a simple way to keep Nod32 from running without uninstalling it, and unfortunately, since I'm working from a production laptop, I'm not able to uninstall Nod32 right now.

Also tried different settings for Nod32 protection but without result.
The 'dead tabs' sometimes happens when I open a link from Skype even if It a first tab, I did not notice the correlation between number of opened tabs and 'dead tabs'

(In reply to n.marti from comment #27)

(In reply to n.marti from comment #26)

I too have ESET Nod32 installed. I've just turned off real-time protection to see if the problem goes away. I'll report back in a day or so. I'm now running 72.0.1, still with cinnamon-desktop and ubuntu 18.04.

So, with ESET Nod32 installed but with "Real-time file system protection" disabled, I still got a dead tab after opening about 7-10 of them. It's not clear to me if there's a simple way to keep Nod32 from running without uninstalling it, and unfortunately, since I'm working from a production laptop, I'm not able to uninstall Nod32 right now.

My solution for now:

  1. Short script:
    pkill "IPC Launch #1"

  2. run it by CRON every few minutes.

Recently my company decided to standardize all the workstations. The OS chosen was Ubuntu 18.04 (LTS) with basically all possible window managers available. I use the Plasma Desktop, and I never found this bug on my previous machine, which was running Kubuntu 19.10. The dead tab happened after these actions:

  1. Clicking on a link TOP Sites
  2. Opening a new tab and typing an address.
  3. CTRL+click a link on an website
  4. middle click a link on an website

On cases 1 and 2, the current tab shows the dots as if it was loading a website, but nothing happens. No "connect" or "waiting" message on the bottom of the page or anything. This tab will be completely dead.

On cases 3 and 4, the new tab is created, on the name it shows the beginning of the URL, but it never loads, it does nothing in fact. I ran it from the command line, no message on the console. This also happened on the Ubuntu build.

I'm attaching a screenshot of my tabs after triggering the error. The last two tabs should be the same, I middle clicked twice on an link. The first time it worked, the second it was a dead tab

**NO BUGS HERE**
Operating System: Kubuntu 19.10
KDE Plasma Version: 5.16.5
KDE Frameworks Version: 5.62.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-29-generic
OS Type: 64-bit

**BUG HAPPENS HERE**
Operating System: Kubuntu 18.04
KDE Plasma Version: 5.12.9
KDE Frameworks Version: 5.44.0
Qt Version: 5.9.5
Kernel Version: 4.15.0-60-generic
OS Type: 64-bit

**FIREFOX INFO**
Application Basics
------------------
Name: Firefox
Version: 73.0.1
Build ID: 20200217142647
Update Channel: release
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0
OS: Linux 4.15.0-60-generic
Multiprocess Windows: 3/3 Enabled by default
Remote Processes: 8
Enterprise Policies: Inactive
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false

Crash Reports for the Last 3 Days
---------------------------------

Firefox Features
----------------

Name: DoH Roll-Out
Version: 1.3.0
ID: doh-rollout@mozilla.org

Name: Firefox Screenshots
Version: 39.0.0
ID: screenshots@mozilla.org

Name: Form Autofill
Version: 1.0
ID: formautofill@mozilla.org

Name: Web Compat
Version: 7.0.0
ID: webcompat@mozilla.org

Name: WebCompat Reporter
Version: 1.1.0
ID: webcompat-reporter@mozilla.org

Remote Processes
----------------

Type: Web Content
Count: 7 / 8

Type: Extension
Count: 1

Extensions
----------

Name: Amazon.com
Version: 1.1
Enabled: true
ID: amazondotcom@search.mozilla.org

Name: Bing
Version: 1.1
Enabled: true
ID: bing@search.mozilla.org

Name: DuckDuckGo
Version: 1.0
Enabled: true
ID: ddg@search.mozilla.org

Name: eBay
Version: 1.0
Enabled: true
ID: ebay@search.mozilla.org

Name: Facebook Container
Version: 2.0.3
Enabled: true
ID: @contain-facebook

Name: FoxyProxy Standard
Version: 7.4.3
Enabled: true
ID: foxyproxy@eric.h.jung

Name: Google
Version: 1.0
Enabled: true
ID: google@search.mozilla.org

Name: HTTPS Everywhere
Version: 2019.11.7
Enabled: true
ID: https-everywhere@eff.org

Name: Privacy Badger
Version: 2020.2.19
Enabled: true
ID: jid1-MnnxcxisBPnSXQ@jetpack

Name: Privacy Extension For WhatsApp Web
Version: 2.8.1
Enabled: true
ID: contact@lukaslen.com

Name: Reddit Enhancement Suite
Version: 5.18.10
Enabled: true
ID: jid1-xUfzOsOFlzSOXg@jetpack

Name: RESTED
Version: 2.3.1
Enabled: true
ID: rested@restedclient

Name: Stylus
Version: 1.5.10
Enabled: true
ID: {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d}

Name: Twitter
Version: 1.0
Enabled: true
ID: twitter@search.mozilla.org

Name: uBlock Origin
Version: 1.25.0
Enabled: true
ID: uBlock0@raymondhill.net

Name: Wikipedia (en)
Version: 1.0
Enabled: true
ID: wikipedia@search.mozilla.org

Name: Wizdler
Version: 1.32
Enabled: true
ID: {8e591fd4-8923-47d9-be8b-127b215dd95a}
Attached image tab_error.png —

Showing some tabs opened on my browser, the dead tab was the same link as the penultimate one.

Something I forgot to add on my report, even clicking a link on the about:config#privacy page led to a dead tab (this was the link clicked https://bugzilla.mozilla.org/show_bug.cgi?id=1604218#c6)

See Also: → 1620871
See Also: → 1621301

ESET has published an update for their scanner (presumably because there were tons of Chrome users suffering from the same problem). Reportedly it should fix this for Firefox as well, see e.g.: https://bugzilla.mozilla.org/show_bug.cgi?id=1565185#c20

I have this problem pretty much since I stopped using Google Chrome about 4 months ago. I was running an "old" version of ESET (4.0.93). Hopefully 4.0.95 will fix it.

To continue on this bug report, our desktops were updated recently to Ubuntu 20.04, the problem still occurs. Firefox build is 85.0.1 Mozilla Firefox for Ubuntu canonical - 1.0. there is no ESET nod32 installed here, but my harddrive is encrypted. I'm running on KDE:

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-42-generic
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-3470 CPU @ 3.20GHz
Memory: 31,3 GiB of RAM

there is no ESET nod32 installed here

Please file a new bug as that is likely a different problem.

I'm going to close this one as it appears NOD32 was fixed.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

FWIW I understand that you already provided some information in this bug, but it doesn't look related to the original report here and it's important that we can separate the causes out, which is why I'd like to track it separately (in a new bug) - right now there's nothing specific that even gives a hint where the problem could be.

Flags: needinfo?(yohanleafheart)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #38)

FWIW I understand that you already provided some information in this bug, but it doesn't look related to the original report here and it's important that we can separate the causes out, which is why I'd like to track it separately (in a new bug) - right now there's nothing specific that even gives a hint where the problem could be.

No Worries :gcp, I will open another bug and put the information there.

Flags: needinfo?(yohanleafheart)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: