Ubuntu

winbind crashes

Reported by gmoore777 on 2010-10-27
40
This bug affects 6 people
Affects Status Importance Assigned to Milestone
samba (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: samba

Occasionally on various Ubuntu 64-bit LucidLynx systems (10.04.1), winbind goes into a state such that logging in fails.
(we use ActiveDirectory for logging in. We do not use the Likewise-open product.)
Although, it appears that there are 1 or more winbindd processes running, they are all dead/not_working/hung, etc.
The only recourse to fix the problem, is that I log in with a local account that has sudo privilege, find and kill all the
winbindd processes, and restart, nmbd, winbindd and samba. (not sure if I need to restart nmbd and samba, but
I do it anyways.)

This problem seems to happen more often on systems that are shared with other users.
Some of those other users are connected from across the Wan via ssh.
The problem seems to occur more often over the weekend. Meaning, Monday morning,
is when we discover the machines are un-loginable with Active Directory account names.

This problem does not happen with all 80+ machines. All machines are built out the same,
and are on approximately the same type of hardware.

This problem has existed since the onset of LucidLynx from what I can remember.
The problem occurs frequently enough, that I had to set up a self-help web page for users with the
problem. From there I have a script that will log into the machine in question,
with a local sudo privileged account, kills all the winbind processes and restarts
nmbd, winbindd and samba.
Even with using the local account, each command takes about 2 1/2 minutes to complete.
It takes about 12 minutes to accomplish the "fixing" of the machine due to the # of commands that
need to be run.

I am assuming the core file under /var/log/samba/cores/winbindd/core
will be relevant to the problem I am having.

$ lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04

$ apt-cache policy winbind
winbind:
  Installed: 2:3.4.7~dfsg-1ubuntu3.2
  Candidate: 2:3.4.7~dfsg-1ubuntu3.2
  Version table:
 *** 2:3.4.7~dfsg-1ubuntu3.2 0
        500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        500 http://security.ubuntu.com/ubuntu/ lucid-security/main Packages
        100 /var/lib/dpkg/status
     2:3.4.7~dfsg-1ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages

gmoore777 (guy-moore) wrote :
errr (errr-errr) wrote :

I am also having this exact same problem. The only diff is that it does not take a long period of time for us to fix. We can simply service winbind restart and the problem is fixed with in seconds. This has happened twice just this week, and has been happening about once per week since we started using Ubuntu. We were previously on a FreeBSD system that was not using AD for authentication. I have looked in the log.winbind and in the winbind.log nothing of much help is found there.

The following message is repeated over and over in winbind.log:
 [2010/10/29 05:37:07, 1] winbindd/winbindd_util.c:303(trustdom_recv)
  Could not receive trustdoms

This message begins at the same time the service becomes unavailable. I know this because we have Nagios setup to monitor and we get alerts from Nagios that correlate with the logs.

The only messages found in log.winbind are the messages that show we started the service:
 => zcat log.winbindd.1.gz
[2010/10/25 08:01:07, 0] winbindd/winbindd.c:1252(main)
  winbindd version 3.4.7 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009
=> cat log.winbindd
[2010/10/29 07:46:28, 0] winbindd/winbindd.c:1252(main)
  winbindd version 3.4.7 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009

I am not seeing any core files in /var/log/samba/cores/*

Mathias Gug (mathiaz) on 2010-11-02
Changed in samba (Ubuntu):
importance: Undecided → Medium
gmoore777 (guy-moore) wrote :

from my original post, I want to strike that there is a core file. Since then I have looked for a core file when the problem happens, and it is not there. So don't waste time debugging the attached core file.

In regards to errr's note above, maybe why it is quick for him/her to fix, is that they are not using ActiveDirectory/LDAP
and I am, and there is some time out period, and # of retries that "something" tries to do, hence why it takes about
2 1/2 minutes (5 tries of 30 second wait times each, maybe?) for me to get any command to complete.

Restarting winbindd, does not always work (possibly never works). Well it may seem that it works, but there are
still old winbindd processes still hanging around. Hence why my protocol is to `kill -9` the windbindd processes first.
Then, restarting winbind via: `sudo /etc/init.d/winbind restart`

Same as errr's comment above, that there is nothing in the log.winbindd file, except:

    [2010/11/03 16:25:25, 0] winbindd/winbindd.c:1252(main)
         winbindd version 3.4.7 started.
         Copyright Andrew Tridgell and the Samba Team 1992-2009
    [2010/11/03 16:25:25, 1] lib/tdb_validate.c:446(tdb_validate_and_backup)
         tdb '/var/cache/samba/winbindd_cache.tdb' is valid
    [2010/11/03 16:25:25, 1] lib/tdb_validate.c:456(tdb_validate_and_backup)
           Created backup '/var/cache/samba/winbindd_cache.tdb.bak' of tdb '/var/cache/samba/winbindd_cache.tdb'

Chuck Short (zulcss) wrote :

Could you please install the samba-dbg package and try to reproduce?

Thanks
chuck

Changed in samba (Ubuntu):
status: New → Incomplete
gmoore777 (guy-moore) wrote :

I have just installed the samba-dbg package.
When this problem happens again, what do I need to run, look at, provide back to this forum, etc?

gmoore777 (guy-moore) wrote :

I didn't specifically reproduce the problem, but the problem has happened, on its own.
There also happens to be a recent core file around.

    $ sudo find /var/log -type f | grep core | xargs sudo ls -al
    -rw------- 1 root root 1564672 2010-12-27 04:12 /var/log/samba/cores/winbindd/core

I then run `gdb winbindd`, "core core", and then "bt" for a backtrace:

Program terminated with signal 6, Aborted.
#0 0x00007f5862af1a75 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007f5862af1a75 in raise () from /lib/libc.so.6
#1 0x00007f5862af55c0 in abort () from /lib/libc.so.6
#2 0x00007f5864f97430 in dump_core () at lib/fault.c:337
#3 0x00007f5864fa825e in smb_panic (why=<value optimized out>) at lib/util.c:1496
#4 0x00007f5864f9782d in fault_report (sig=11) at lib/fault.c:52
#5 sig_fault (sig=11) at lib/fault.c:75
#6 <signal handler called>
#7 get_cache (domain=0x0) at winbindd/winbindd_cache.c:139
#8 0x00007f5864f0a888 in resolve_username_to_alias (mem_ctx=<value optimized out>, domain=0x0, name=0x7f5866dadf70 "puneet.arora", alias=0x7fff22b0bb00)
    at winbindd/winbindd_cache.c:1019
#9 0x00007f5864efd016 in normalize_name_map (mem_ctx=0x7f5866d56530, domain=0x0, name=0x7f5866dadf70 "puneet.arora", normalized=0x7fff22b0bb00)
    at winbindd/winbindd_util.c:1442
#10 0x00007f5864efb6ef in fill_grent_mem_domusers (domain=0x7f5866db2d60, state=<value optimized out>, group_sid=0x7f5866d6eed0,
    group_name_type=<value optimized out>, num_gr_mem=<value optimized out>, gr_mem=<value optimized out>, gr_mem_len=0x7fff22b0beb8)
    at winbindd/winbindd_group.c:330
#11 fill_grent_mem (domain=0x7f5866db2d60, state=<value optimized out>, group_sid=0x7f5866d6eed0, group_name_type=<value optimized out>,
    num_gr_mem=<value optimized out>, gr_mem=<value optimized out>, gr_mem_len=0x7fff22b0beb8) at winbindd/winbindd_group.c:578
#12 0x00007f5864efba9f in getgrsid_sid2gid_recv (private_data=0x7f5866d6eeb0, success=<value optimized out>, gid=563) at winbindd/winbindd_group.c:866
#13 0x00007f5864ef4b98 in process_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at winbindd/winbindd.c:1109
#14 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at winbindd/winbindd.c:1434

Is this helpful?

Chuck Short (zulcss) wrote :

Thanks

Changed in samba (Ubuntu):
status: Incomplete → Confirmed
gmoore777 (guy-moore) wrote :

Can we get some traction on this bug?

This problem still consistently occurs on at least 5 machines per week out of our 80 machines.
Or throw me some ideas to either narrow down the problem further or work-arounds.

I still feel that whatever winbind does to keep itself busy while being idle is causing it to go into this unresponsive state.
Is it pinging our Active Directory server every X minutes and amassing a queue of awaiting responses back?
Is it pinging DNS servers every X minutes, etc.
It must be doing something, other than just merely authenticating
a user when they log in. I think these background tasks is the core of the problem.
I also can't believe no one is reporting this, unless we are the only establishment using ActiveDirectory on Ubuntu.
Help, please.

errr (errr-errr) wrote :

gmoore777,
To work around it I am using daemontools http://cr.yp.to/daemontools.html so when it crashes it just spawns right back up. I have noticed that once it wasnt working but was still running so I also added to my crontab @daily svc -d /service/winbind;svc -u /service/winbind and since doing that I have had not had to log in and manually do anything to fix it.. sucky work around but its all I have found

Mau (maugarta-cc) wrote :
Download full text (3.3 KiB)

Hi,
I also have same problem since last winbind update 3 days ago. I use winbind to provide system authenticatio/authorization in a MS Active Directory domain.

Here are provided information when winbind crashes. I hope it is useful:

[Thread debugging using libthread_db enabled]
0x00007fac5d842f7e in __libc_waitpid (pid=<value optimized out>,
    stat_loc=0x7fffd473651c, options=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/waitpid.c:32
 in ../sysdeps/unix/sysv/linux/waitpid.c
#0 0x00007fac5d842f7e in __libc_waitpid (pid=<value optimized out>,
    stat_loc=0x7fffd473651c, options=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/waitpid.c:32
#1 0x00007fac5d7da7e9 in do_system (line=<value optimized out>)
    at ../sysdeps/posix/system.c:149
#2 0x00007fac5fc83264 in smb_panic (why=<value optimized out>)
    at lib/util.c:1486
#3 0x00007fac5fc7284d in fault_report (sig=11) at lib/fault.c:52
#4 sig_fault (sig=11) at lib/fault.c:75
#5 <signal handler called>
#6 rpc_pipe_np_smb_conn (p=0x0) at rpc_client/rpc_transport_np.c:402
#7 0x00007fac5fd5e048 in rpccli_set_timeout (rpc_cli=0x0, timeout=35000)
    at rpc_client/cli_pipe.c:2956
#8 0x00007fac5fbf87a1 in winbindd_lookup_sids (mem_ctx=0x7fac61d17f10,
    domain=<value optimized out>, num_sids=<value optimized out>,
    sids=<value optimized out>, domains=0x7fffd4736b08, names=0x7fffd4736b00,
    types=0x7fffd4736af8) at winbindd/winbindd_rpc.c:1221
#9 0x00007fac5fbf8ac2 in msrpc_sid_to_name (domain=0x7fac61c89970,
    mem_ctx=0x7fac61d17f10, sid=0x7fffd4736db0,
    domain_name=<value optimized out>, name=0x7fffd4736e28,
    type=0x7fffd4736e50) at winbindd/winbindd_rpc.c:345
#10 0x00007fac5fbf99df in sid_to_name (domain=0x0, mem_ctx=0x88b8, sid=0x0,
    domain_name=0x17d50, name=0x7fac61d28740, type=0x1)
    at winbindd/winbindd_reconnect.c:118
#11 0x00007fac5fbf9f0e in sid_to_name (domain=0x0, mem_ctx=0x88b8, sid=0x0,
    domain_name=0x17d50, name=0x7fac61d28740, type=0x1)
    at winbindd/winbindd_ads.c:426
#12 0x00007fac5fbe38bc in sid_to_name (domain=0x7fac61c89970,
    mem_ctx=<value optimized out>, sid=0x7fffd4736db0,
    domain_name=0x7fffd4736e30, name=0x7fffd4736e28,
    type=<value optimized out>) at winbindd/winbindd_cache.c:1729
#13 0x00007fac5fbd6477 in fill_grent_mem_domusers (domain=0x7fac61c89970,
    state=<value optimized out>, group_sid=0x7fac61d245b0,
    group_name_type=<value optimized out>, num_gr_mem=<value optimized out>,
    gr_mem=<value optimized out>, gr_mem_len=0x7fffd47371d8)
    at winbindd/winbindd_group.c:315
#14 fill_grent_mem (domain=0x7fac61c89970, state=<value optimized out>,
    group_sid=0x7fac61d245b0, group_name_type=<value optimized out>,
    num_gr_mem=<value optimized out>, gr_mem=<value optimized out>,
    gr_mem_len=0x7fffd47371d8) at winbindd/winbindd_group.c:578
#15 0x00007fac5fbd6a9f in getgrsid_sid2gid_recv (private_data=0x7fac61d24590,
    success=<value optimized out>, gid=10000) at winbindd/winbindd_group.c:866
#16 0x00007fac5fbcfba0 in process_loop (argc=<value optimized out>,
    argv=<value optimized out>, envp=<value optimized out>)
    at winbindd/winbindd.c:1115
#17 main (argc=<value opti...

Read more...

Darren Faulke (darren-alidaf) wrote :

I still have this problem on a hardy (8.04 x64) machine. All servers that were upgraded to lucid (10.04 x64) were fixed until the latest update. I have to manually restart winbind, which takes seconds but is an inconvenience and requires me to be around to do it. I tried a cron to restart winbind every so often but it didn't work. It always occurs in the morning as more people attempt to log in. I have around 20 users and typically have to restart winbind 1 or 2 times a day for each server.

wulu (wulu) wrote :

Same here,
using ActiveDirectory, 10.04.2 LTS x64.
winbind/lucid uptodate 2:3.4.7~dfsg-1ubuntu3.5

Whenever the DC that is configured in /etc/krb5.conf is restartet, winbind will crash afterwards.

This seems to happen after the DC rebooted to install updates.

BACKTRACE: 14 stack frames:
#0 /usr/sbin/winbindd(log_stack_trace+0x1a) [0x7ff49105d17a]
#1 /usr/sbin/winbindd(smb_panic+0x1f) [0x7ff49105d23f]
#2 /usr/sbin/winbindd(+0x14384d) [0x7ff49104c84d]
#3 /lib/libc.so.6(+0x33af0) [0x7ff48eba6af0]
#4 /usr/sbin/winbindd(rpc_pipe_np_smb_conn+0x4) [0x7ff49113f204]
#5 /usr/sbin/winbindd(rpccli_set_timeout+0x8) [0x7ff491138048]
#6 /usr/sbin/winbindd(winbindd_lookup_sids+0xb1) [0x7ff490fd27a1]
#7 /usr/sbin/winbindd(+0xcc092) [0x7ff490fd5092]
#8 /usr/sbin/winbindd(+0xb3503) [0x7ff490fbc503]
#9 /usr/sbin/winbindd(+0xa65e7) [0x7ff490faf5e7]
#10 /usr/sbin/winbindd(+0xa7a9f) [0x7ff490fb0a9f]
#11 /usr/sbin/winbindd(main+0xd20) [0x7ff490fa9ba0]
#12 /lib/libc.so.6(__libc_start_main+0xfd) [0x7ff48eb91c4d]
#13 /usr/sbin/winbindd(+0x9e3f9) [0x7ff490fa73f9]

gmoore777 (guy-moore) wrote :

I thought I would just add another backtrace from a core file that occurred today on a machine where winbind
crashed several times:

#0 0x00007f089b9b6a75 in raise () from /lib/libc.so.6
#1 0x00007f089b9ba5c0 in abort () from /lib/libc.so.6
#2 0x00007f089de5c450 in dump_core () at lib/fault.c:337
#3 0x00007f089de6d27e in smb_panic (why=<value optimized out>) at lib/util.c:1496
#4 0x00007f089de5c84d in fault_report (sig=11) at lib/fault.c:52
#5 sig_fault (sig=11) at lib/fault.c:75
#6 <signal handler called>
#7 rpc_pipe_np_smb_conn (p=0x0) at rpc_client/rpc_transport_np.c:402
#8 0x00007f089df48048 in rpccli_set_timeout (rpc_cli=0x0, timeout=35000) at rpc_client/cli_pipe.c:2956
#9 0x00007f089dde27a1 in winbindd_lookup_sids (mem_ctx=0x7f089e746290, domain=<value optimized out>, num_sids=<value optimized out>,
    sids=<value optimized out>, domains=0x7fffa6901bd0, names=0x7fffa6901be0, types=0x7fffa6901bd8) at winbindd/winbindd_rpc.c:1221
#10 0x00007f089dde5092 in lookup_groupmem (domain=0x7f089e7a4a00, mem_ctx=0x7f089e745eb0, group_sid=0x7f089e79ca60, num_names=0x7fffa6901f1c,
    sid_mem=<value optimized out>, names=<value optimized out>, name_types=0x7fffa6901ee8) at winbindd/winbindd_ads.c:1124
#11 0x00007f089ddcc503 in lookup_groupmem (domain=<value optimized out>, mem_ctx=<value optimized out>, group_sid=<value optimized out>,
    num_names=0x7fffa6901f1c, sid_mem=0x7fffa6901ed8, names=0x7fffa6901ee0, name_types=0x7fffa6901ee8) at winbindd/winbindd_cache.c:2211
#12 0x00007f089ddbf5e7 in expand_groups (domain=0x7f089e7a4a00, state=<value optimized out>, group_sid=<value optimized out>,
    group_name_type=SID_NAME_DOM_GRP, num_gr_mem=<value optimized out>, gr_mem=<value optimized out>, gr_mem_len=0x7fffa69022a8)
    at winbindd/winbindd_group.c:468
#13 fill_grent_mem (domain=0x7f089e7a4a00, state=<value optimized out>, group_sid=<value optimized out>, group_name_type=SID_NAME_DOM_GRP,
    num_gr_mem=<value optimized out>, gr_mem=<value optimized out>, gr_mem_len=0x7fffa69022a8) at winbindd/winbindd_group.c:604
#14 0x00007f089ddc0a9f in getgrsid_sid2gid_recv (private_data=0x7f089e767140, success=<value optimized out>, gid=4549) at winbindd/winbindd_group.c:866
#15 0x00007f089ddb9ba0 in process_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at winbindd/winbindd.c:1115
#16 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at winbindd/winbindd.c:1440

Chuck Short (zulcss) wrote :

Can you try the version in lucid proposed please?

Thanks
chuck

gmoore777 (guy-moore) wrote :

I just did a backtrace on another machine(bee37), of another core file, the back trace takes a different path, but the final 3 calls are the same as my previous post and the same last e calls as Mau's back trace:

rpc_pipe_np_smb_conn
rpccli_set_timeout
winbindd_lookup_sids
...

Unfortunately these 3 back traces that have the same last 3 calls, are all different than my original backtrace I posted on 12/27/2010,
but I'll take any winbind fix for any problem at this point.

I had 22 of 80 machines experience a winbind
problem yesterday, Monday 2011-04-18.

I will throw one red herring of an idea out there.
Is it possible that the cause of this is
if a user is in a Windows group per his poilicy file but that group isn't active anymore?
winbind can work for days at a time, so this problem is not deterministic. There's some
other factor that is causing this to happen, and I can't figure it out.

gmoore777 (guy-moore) wrote :

Please, can someone raise the importance of this bug from Medium to whatever the highest level is.
This winbind crashing problem is critical for us and is occurring with more frequency on more machines,
daily if not hourly. It's affecting the confidence level of all our developers and QA.

gmoore777 (guy-moore) wrote :

1.)
Per https://launchpad.net/ubuntu/lucid/+package/winbind
there are several "proposed" versions to choose from:
winbind 2:3.4.7~dfsg-1ubuntu3.5 in amd64 (Proposed)
winbind 2:3.4.7~dfsg-1ubuntu3.6 in amd64 (Proposed)

i will choose the newer "3.6"
winbind 2:3.4.7~dfsg-1ubuntu3.6 in amd64 (Proposed)

since the version that is currently installed is:
 2:3.4.7~dfsg-1ubuntu3.5

2.)
I will also purge the samba-dbg package in case that is conflicting.

3.)
I will choose 2 machines to install the winbind 2:3.4.7~dfsg-1ubuntu3.6 in amd64 (Proposed)
and then wait and see what happens...

gmoore777 (guy-moore) wrote :

Instead of downloading the .deb files, i did the more appropriate,
SynapticPackageManager --> repositories --> Updates and
Click "Pre-released updated (lucid-proposed)" check box
which when installing winbind, it pulled in the proposed
versions of libwbclient0, samba, samba-common, and smbclient.
I did this on 2 machines (bee02 and bee75).
Will wait for winbind to crash.

gmoore777 (guy-moore) wrote :

It's been 36 hours, and have not got the "rpc_pipe_np_smb_conn" crash on any of the 3 machines that I installed the 2:3.4.7~dfsg-1ubuntu3.6 package.
This particular "rpc_pipe_np_smb_conn" crash, as I call it, is covered here https://bugs.launchpad.net/ubuntu/+source/samba/+bug/753330.

So once this ~dfsg-1ubuntu3.6 package package is made generally available and I install it on my 80 machines, then I will go back to the original problem that I initiated here and try to get more information for you all.

gmoore777 (guy-moore) wrote :

similar to the stack trace in comment #6 above, winbind crashed today (on machine bee64) with this stack trace as gotten from gdb against the core file left behind:

(gdb) bt
#0 0x00007f70d81fda75 in raise () from /lib/libc.so.6
#1 0x00007f70d82015c0 in abort () from /lib/libc.so.6
#2 0x00007f70da6a3460 in dump_core () at lib/fault.c:337
#3 0x00007f70da6b428e in smb_panic (why=<value optimized out>) at lib/util.c:1496
#4 0x00007f70da6a385d in fault_report (sig=11) at lib/fault.c:52
#5 sig_fault (sig=11) at lib/fault.c:75
#6 <signal handler called>
#7 get_cache (domain=0x0) at winbindd/winbindd_cache.c:139
#8 0x00007f70da616888 in resolve_username_to_alias (mem_ctx=<value optimized out>, domain=0x0, name=0x7f70db4aacb0 "gautam.naik", alias=0x7fffab4a4110) at winbindd/winbindd_cache.c:1019
#9 0x00007f70da609016 in normalize_name_map (mem_ctx=0x7f70db496180, domain=0x0, name=0x7f70db4aacb0 "gautam.naik", normalized=0x7fffab4a4110) at winbindd/winbindd_util.c:1442
#10 0x00007f70da6076ef in fill_grent_mem_domusers (domain=0x7f70db4b0d40, state=<value optimized out>, group_sid=0x7f70db46ced0, group_name_type=<value optimized out>,
    num_gr_mem=<value optimized out>, gr_mem=<value optimized out>, gr_mem_len=0x7fffab4a44c8) at winbindd/winbindd_group.c:330
#11 fill_grent_mem (domain=0x7f70db4b0d40, state=<value optimized out>, group_sid=0x7f70db46ced0, group_name_type=<value optimized out>, num_gr_mem=<value optimized out>,
    gr_mem=<value optimized out>, gr_mem_len=0x7fffab4a44c8) at winbindd/winbindd_group.c:578
#12 0x00007f70da607a9f in getgrsid_sid2gid_recv (private_data=0x7f70db46ceb0, success=<value optimized out>, gid=563) at winbindd/winbindd_group.c:866
#13 0x00007f70da600ba0 in process_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at winbindd/winbindd.c:1115
#14 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at winbindd/winbindd.c:1440

I am running the latest winbind of 2:3.4.7~dfsg-1ubuntu3.6

So the problem still persists after upgrading to 2:3.4.7~dfsg-1ubuntu3.6.

What other information do you want me to provide?

Jameel Akari (jakari-3) wrote :

Any update on this?

I'm seeing the same sorts of problems (10.04 LTS), winbind updated to current as of today.
2:3.4.7~dfsg-1ubuntu3.10

It seems to help, somewhat, if I crank up "winbind cache time."

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers