[Bug 1842447] Re: Kernel Panic with linux-image-4.15.0-60-generic when specifying nameserver in docker-compose
FTR, 4.15.0-62 seems *much* better than 4.15.0-60. With 4.15.0-60 this system was kernel panic restarting every 75-90 minutes; now it's been up since I installed 4.15.0-62, over 5 hours ago: -=- cut here -=- ewen@naosr620:~$ uname -r 4.15.0-62-generic ewen@naosr620:~$ uptime 16:09:54 up 5:26, 1 user, load average: 0.24, 0.25, 0.24 ewen@naosr620:~$ -=- cut here -=- That one line fix seems important :-) Ewen -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1842447 Title: Kernel Panic with linux-image-4.15.0-60-generic when specifying nameserver in docker-compose To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842447/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1842447] Re: Kernel Panic with linux-image-4.15.0-60-generic when specifying nameserver in docker-compose
FTR, I think this is the fix in -62: https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/?h=master- next=b502cfeffec81be8564189e5498fd3f252b27900 and it appears to be the only change from -60 to -62: -=- cut here -=- ewen@naosr620:~$ zcat /usr/share/doc/linux-headers-4.15.0-62-generic/changelog.Debian.gz | head -9 linux (4.15.0-62.69) bionic; urgency=medium * bionic/linux: 4.15.0-62.69 -proposed tracker (LP: #1842746) * Kernel Panic with linux-image-4.15.0-60-generic when specifying nameserver in docker-compose (LP: #1842447) - ip: frags: fix crash in ip_do_fragment() -- Khalid Elmously Wed, 04 Sep 2019 16:11:43 -0400 ewen@naosr620:~$ -=- cut here -=- It's a one line fix. Ewen -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1842447 Title: Kernel Panic with linux-image-4.15.0-60-generic when specifying nameserver in docker-compose To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842447/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1843152] Re: Kernel Panic with linux kernel 4.15.0-60 possibly related to network subsystem
These symptoms sound very much like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842447 (I found the bug I'm commenting on while searching for additional links about the issue in 1842447). There's a -62 kernel in proposed updates which hopefully contains the fix for this bug. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842447 for hints on how to install the proposed update kernel. So far the trigger is sounding like NAT + 4.15.0-60 kernel + sufficient time that the relevant uninitialised variable is not clean from boot. I think this is the fix in -62: https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/?h=master- next=b502cfeffec81be8564189e5498fd3f252b27900 Ewen -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843152 Title: Kernel Panic with linux kernel 4.15.0-60 possibly related to network subsystem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1843152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1842447] Re: Kernel Panic with linux-image-4.15.0-60-generic when specifying nameserver in docker-compose
I agree with Taher (in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842447/comments/15), this bug seems to impact a lot of systems (my colo host was kernel panic restarting about every 75-90 minutes, all weekend). It has a NAT firewall on it (for the hosted VMs), but no Docker/Wireguard, etc. My guess for the 75-90 minutes is that is how long it took to dirty enough memory that the relevant value just happened not to already be 0 (NULL). (Curiously I installed -60 on Thursday last week, and the first issue didn't happen until Friday, so it's been worse over the weekend than the first 24 hours. I enabled kernel.panic=15 after the first issue, to automate recovery, and was *extremely* glad I did so.) Honestly I'd suggest withdrawing -60 as it's very unstable in a lot of common configurations. And also suggest expediting the release of -62, which AFAICT just contains the one line fix for the bug in -60. Now it's Monday morning (and thus I can get into the colo if needed), I've upgraded the colo system to the proposed -62 version, and crossing my fingers the system is more stable as a result. In case it helps others, I found I needed to: (a) https://wiki.ubuntu.com/Testing/EnableProposed (changing "xenial" to "bionic", for 18.04 LTS, including enabling the low priority pin of bionic-proposed); and (b) sudo apt-get install linux-generic/bionic-proposed linux-signed- generic/bionic-proposed linux-headers-generic/bionic-proposed (without at least two of those three, the proposed update metapackages wouldn't install due to conflicts; I'm not sure if linux-signed-generic is needed, but it's still installed, so I chose to keep it in sync.) That list of packages found by looking for 4.15.0-60 versioned packages that didn't have that version in their package name (ie, to find the generic metapackages). Ewen PS: Reboots (due to kernel panic, and kernel.panic=15 sysctl) over the weekend: -=- cut here -=- ewen@naosr620:~$ last | grep reboot reboot system boot 4.15.0-62-generi Mon Sep 9 10:43 still running reboot system boot 4.15.0-60-generi Mon Sep 9 10:14 - 10:39 (00:25) reboot system boot 4.15.0-60-generi Mon Sep 9 08:48 - 10:09 (01:21) reboot system boot 4.15.0-60-generi Mon Sep 9 07:33 - 10:09 (02:36) reboot system boot 4.15.0-60-generi Mon Sep 9 06:18 - 10:09 (03:51) reboot system boot 4.15.0-60-generi Mon Sep 9 05:03 - 10:09 (05:06) reboot system boot 4.15.0-60-generi Mon Sep 9 03:48 - 10:09 (06:21) reboot system boot 4.15.0-60-generi Mon Sep 9 02:33 - 10:09 (07:36) reboot system boot 4.15.0-60-generi Mon Sep 9 01:13 - 10:09 (08:56) reboot system boot 4.15.0-60-generi Sun Sep 8 23:58 - 10:09 (10:11) reboot system boot 4.15.0-60-generi Sun Sep 8 22:43 - 10:09 (11:26) reboot system boot 4.15.0-60-generi Sun Sep 8 21:28 - 10:09 (12:41) reboot system boot 4.15.0-60-generi Sun Sep 8 20:08 - 10:09 (14:01) reboot system boot 4.15.0-60-generi Sun Sep 8 18:53 - 10:09 (15:16) reboot system boot 4.15.0-60-generi Sun Sep 8 17:38 - 10:09 (16:31) reboot system boot 4.15.0-60-generi Sun Sep 8 16:23 - 10:09 (17:46) reboot system boot 4.15.0-60-generi Sun Sep 8 15:08 - 10:09 (19:01) reboot system boot 4.15.0-60-generi Sun Sep 8 13:53 - 10:09 (20:16) reboot system boot 4.15.0-60-generi Sun Sep 8 12:29 - 10:09 (21:40) reboot system boot 4.15.0-60-generi Sun Sep 8 11:14 - 10:09 (22:55) reboot system boot 4.15.0-60-generi Sun Sep 8 09:57 - 10:09 (1+00:12) reboot system boot 4.15.0-60-generi Sun Sep 8 08:43 - 10:09 (1+01:26) reboot system boot 4.15.0-60-generi Sun Sep 8 07:28 - 10:09 (1+02:41) reboot system boot 4.15.0-60-generi Sun Sep 8 06:13 - 10:09 (1+03:56) reboot system boot 4.15.0-60-generi Sun Sep 8 04:54 - 10:09 (1+05:15) reboot system boot 4.15.0-60-generi Sun Sep 8 03:34 - 10:09 (1+06:35) reboot system boot 4.15.0-60-generi Sun Sep 8 02:18 - 10:09 (1+07:51) reboot system boot 4.15.0-60-generi Sun Sep 8 01:03 - 10:09 (1+09:06) reboot system boot 4.15.0-60-generi Sat Sep 7 23:48 - 10:09 (1+10:21) reboot system boot 4.15.0-60-generi Sat Sep 7 22:55 - 10:09 (1+11:14) reboot system boot 4.15.0-60-generi Sat Sep 7 22:34 - 10:09 (1+11:35) reboot system boot 4.15.0-60-generi Sat Sep 7 21:19 - 10:09 (1+12:50) reboot system boot 4.15.0-60-generi Sat Sep 7 20:03 - 10:09 (1+14:06) reboot system boot 4.15.0-60-generi Sat Sep 7 18:48 - 10:09 (1+15:21) reboot system boot 4.15.0-60-generi Sat Sep 7 17:33 - 10:09 (1+16:36) reboot system boot 4.15.0-60-generi Sat Sep 7 16:18 - 10:09 (1+17:51) reboot system boot 4.15.0-60-generi Sat Sep 7 15:03 - 10:09 (1+19:06) reboot system boot 4.15.0-60-generi Sat Sep 7 13:42 - 10:09 (1+20:27) reboot system boot 4.15.0-60-generi Sat Sep 7 12:27 - 10:09 (1+21:42) reboot system boot 4.15.0-60-generi Sat Sep 7 11:12 - 10:09 (1+22:57) reboot system boot 4.15.0-60-generi Sat Sep 7 10:57 - 10:09 (1+23:12)
[Bug 1015199] Re: ifup does not work as documented with bonding interfaces
FTR, system did boot to working network interfaces with the above configuration (including pre-up/sleep lines). I'm not sure if there were warnings issued as the default Ubuntu last action on boot is to clear all boot messages in favour of displaying the login prompt at the top of the screen :-( (/var/log/boot.log contains no messages other than "starting ..." lines.) FWIW, it seems to me that "ifup bond0" should do the enslaving immediately of any bond-slave interfaces that actually already exist; leaving (and maybe waiting for at least one of ) any others that don't currently exist to appear and auto-config later on. That should work both with races on discover on first boot, and through ifdown/ifup bond0 cycle later on (when the slave interfaces most likely still exist, even though they've been disabled by the ifdown bond0). Ewen -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1015199 Title: ifup does not work as documented with bonding interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1015199/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1015199] Re: ifup does not work as documented with bonding interfaces
Even with the apparently fixed version, this "does not work after ifdown bond0/ifup bond0 cycle" appears to persist: -=- cut here -=- ewen@nas06:~$ cat /etc/issue Ubuntu 14.04.4 LTS \n \l ewen@nas06:~$ dpkg -l | grep ifenslave ii ifenslave2.4ubuntu1.2 all configure network interfaces for parallel routing (bonding) ewen@nas06:~$ -=- cut here -=- -=- cut here -=- root@nas06:~# ifdown bond0 em1=em1 em2=em2 root@nas06:~# ifup bond0 Waiting for a slave to join bond0 (will timeout after 60s) No slave joined bond0, continuing anyway root@nas06:~# ifup em1 root@nas06:~# ifup em2 root@nas06:~# -=- cut here -=- After "ifdown bond0" the link does not work properly again until "ifup bond0" is done, followed by "ifup" on the individual interfaces. Which appears to be because "ifdown bond0" disables much more than "ifup bond0" is willing to enable. In particular it appears that "ifup bond0" does not make any attempt to start the slave interfaces -- it seems to solely rely on them being auto-started, which happens only on discover on boot. The only way I seem to be able to get semi-sane behaviour is to add: -=- cut here -=- pre-up (sleep 2 && ifup em1) & pre-up (sleep 2 && ifup em2) & -=- cut here -=- to the bond0 interface stanza. It has to: (a) be pre-up, because post-up is called only after the 60 second up delay; and (b) be delayed, because bond0 won't exist without an modprobe.d alias, until "ifup bond0" has mostly completed. Which feels very fragile. Surely the network scripts for ifenslave could iterate over bond-slaves and do the equivalent of "ifup" on those slave interfaces (or just enslave them directly)? Or have some other way to indicate the interfaces to auto-start. Given that the scripts are already auto- stopping them. BTW, the documentation in README.Debian.gz is clearly wrong: -=- cut here -=- A bonding master is defined like this: iface bond0 inet static address 208.77.188.166 ... bond-primary eth0 eth1 The bonding slaves should then be defined like this: [...] -=- cut here -=- as the whole bonding configuration in bond0 will be ignored if it does not contain "bond-slaves" (as noted later in the file). My current configuration (works with the "pre-up" lines; fails "ifdown bond0; sleep 5; ifup bond0" cycle without): -=- cut here -=- auto em1 allow-bond0 em1 iface em1 inet manual bond-master bond0 auto em2 allow-bond0 em2 iface em2 inet manual bond-master bond0 auto bond0 iface bond0 inet static address [...] bond-mode 802.3ad bond-primary em1 em2 bond-slaves em1 em2 bond-downdelay 200 bond-updelay 200 bond-miimon 100 bond-lacp-rate 1 pre-up (sleep 2 && ifup em1) & pre-up (sleep 2 && ifup em2) & -=- cut here -=- (I've not yet rebooted to see what happens then, but I'm hopeful worst case I get some warnings about interfaces already being up.) Ewen PS: Ironically the referenced bug (https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1337873) says in a comment: -=- cut here -=- In your case ifupdown will be responsible for bringing eth2 and eth3 devices while setting up bond0, so you don't need to undertake any additional actions in the bond0 section - please depend on this. -=- cut here -=- which does not appear to be something that one can depend on :-( -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1015199 Title: ifup does not work as documented with bonding interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1015199/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1393768] Re: modifying /etc/default/postgrey variable "POSTGREY_TEXT" does not change postgrey text when an email is greylisted
I ran into what looked like this problem (on Ubuntu 14.04 LTS, with the
postgrey 1.34-1.2 package).
After a bunch of debugging it turned out that neither "service postgrey
stop" nor "service postgrey restart" were actually _stopping_ the
postgrey daemon, which meant it never started with the new parameters
(which meant it kept using the default text). Once I realised that and
manually killed the old postgrey daemon ("ps ax | grep postgrey", "kill
$PID") and verified it was gone, I could then do "service postgrey
start" and (a) the new text appeared on the command line ("ps ax | grep
postgrey") and (b) the new text was used in the log/SMTP session.
So it appears the root cause is that "service postgrey stop" does not in
fact result in stopping postgrey, despite claiming to. (Even when run
with "sudo") Because the "stop" has "oknodo" and "quiet" on it,
there's apparently no logging of the fact nothing stopped.
-=- cut here -=-
ewen@imatixmailweb:~$ ps axu | grep [p]ostgrey
postgrey 11217 0.0 1.1 17912 11004 ?Ss 03:05 0:00
/usr/sbin/postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=10023
--greylist-text=Your message has been greylisted. Please retry in %s seconds.
ewen@imatixmailweb:~$ sudo start-stop-daemon --stop --oknodo --quiet --pidfile
/var/run/postgrey.pid --name postgrey
ewen@imatixmailweb:~$ ps axu | grep [p]ostgrey
postgrey 11217 0.0 1.1 17912 11004 ?Ss 03:05 0:00
/usr/sbin/postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=10023
--greylist-text=Your message has been greylisted. Please retry in %s seconds.
ewen@imatixmailweb:~$
-=- cut here -=-
Removing "oknodo" and "quiet" reveals that "stop" is not actually doing
anything:
-=- cut here -=-
ewen@imatixmailweb:~$ sudo start-stop-daemon --stop --pidfile
/var/run/postgrey.pid --name postgrey
No postgrey found running; none killed.
ewen@imatixmailweb:~$ ps axu | grep [p]ostgrey
postgrey 11217 0.0 1.1 17912 11004 ?Ss 03:05 0:00
/usr/sbin/postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=10023
--greylist-text=Your message has been greylisted. Please retry in %s seconds.
ewen@imatixmailweb:~$
-=- cut here -=-
even though it is in fact still running (these tests done after I'd
already done the kill/restart, to try to find out why "stop" didn't).
I think the problem is that the name match doesn't match, because it
works without that:
-=- cut here -=-
ewen@imatixmailweb:~$ sudo start-stop-daemon --stop --pidfile
/var/run/postgrey.pid
ewen@imatixmailweb:~$ ps axu | grep [p]ostgrey
ewen@imatixmailweb:~$
-=- cut here -=-
And I think that in turn is due to postgrey being a Perl script, so the
executable running is perl, not "postgrey". Eg,
-=- cut here -=-
ewen@imatixmailweb:~$ ps axu | grep [p]ostgrey
postgrey 11302 0.0 1.1 17920 10984 ?Ss 03:16 0:00
/usr/sbin/postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=10023
--greylist-text=Your message has been greylisted. Please retry in %s seconds.
ewen@imatixmailweb:~$ sudo ls -l /proc/11302 | grep exe
lrwxrwxrwx 1 root root 0 Sep 9 03:18 exe -> /usr/bin/perl
ewen@imatixmailweb:~$
-=- cut here -=-
which means the "name" check on start-stop-daemon will never match.
It also doesn't help that postgrey is unable to remove its PID file, due
to file permissions:
-=- cut here -=-
Sep 9 03:15:12 imatixmailweb postgrey[11217]: Couldn't unlink
"/var/run/postgrey.pid" [Permission denied]
--= cut here -=-
(written as root, before setuid), leading to:
-=- cut here -=-
* Starting postfix greylisting daemon postgrey
Pid_file "/var/run/postgrey.pid" already exists. Overwriting!
-=- cut here -=-
(And I think basically at this point if you don't see it, it's not
really starting again.)
Ewen
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1393768
Title:
modifying /etc/default/postgrey variable "POSTGREY_TEXT" does not
change postgrey text when an email is greylisted
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgrey/+bug/1393768/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 598242] Re: [LUCID] hp compaq nc6220 no sound after resume Lucid Lynx
lucid-updates appears to be official updates, so with 2.6.32-23-generic fixing the problem and being in lucid-updates it seems to be fixed in an official update. So yes, I think closing the bug with fixed in linux- image 2.6.32-23-generic is appropriate. (It'd be nice to know precisely which change fixed it, in case it gets reverted again, but it's probably not worth the effort of digging through everything that changed between 2.6.32-22-generic and 2.6.32-23-generic, since there's a long list of changes.) Ewen -- [LUCID] hp compaq nc6220 no sound after resume Lucid Lynx https://bugs.launchpad.net/bugs/598242 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 598242] Re: [LUCID] hp compaq nc6220 no sound after resume Lucid Lynx
Prompted by Dennis's comment, I thought I'd be a bit scientific about this, and (a) retested with the packages already installed on my HP NC6220 (behaves as described in bug -- after first suspend audio can be heard through headphones, but not built in speakers), (b) ensure that I had the latest available Ubuntu base packages installed, reboot, and retest, and then (c) try the PPA. What I found was that after installing the packages (without adding the PPA) and restarting, the audio worked correctly through the speakers after suspend/resume. To verify this was the fix, I changed the boot timeout (/etc/default/grub) so that I could choose the kernel running and restarted to test with both the previous kernel package and the current kernel package. - 2.6.32-22-generic: behaves as per bug, after first suspend/resume built in speakers are silent but headphones work (restarting or hibernating makes built in speakers work again) - 2.6.32-23-generic: works properly, even after 10 suspend/resume cycles built in speakers work immediately after resume 2.6.32-23-generic appears to have arrived from lucid-updates, although http://packages.ubuntu.com/ is unable to find it. So without trying the PPA it appears that the issue has been fixed in the linux kernel update 2.6.32-23-generic. There are a number of ALSA updates in 2.6.32-23-generic according to the change log (many from stable kernel update: https://bugs.launchpad.net/ubuntu/+bug/583414), including some relating to PCI Quirks, and 0dB offsets, but it's not obvious to me which of these affect the snd_intel8x0 ALSA driver (as opposed to hda, hda_intel). If Dennis also has 2.6.32-23-generic installed and running (uname -a) then that may be the explanation for his fix as well, rather than the PPA specifically. Ewen -- [LUCID] hp compaq nc6220 no sound after resume Lucid Lynx https://bugs.launchpad.net/bugs/598242 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 598242] Re: [LUCID] hp compaq nc6220 no sound after resume Lucid Lynx
This bug also affects me on a HP NC6220 laptop, with a fresh install of Ubuntu Linux 10.04 (Lucid). It appears to be a reversion of the fix in bug #15 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/15), from 2007 (Fiesty, Gutsty). Prior to that fix the internal speakers stopped working after suspend/resume, but headphones/external speakers worked; after that fix, the internal speakers stayed working over suspend/resume. The same thing is true now (after suspend the internal speakers don't work, but headphones do work). In bug #15 it was tracked down to a specific patch that was applied to break things (and I can confirm that reverting that patch and building a custom module did fix the problem at the time): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/15/comments/1 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/15/comments/7 The resolution of bug #15 was to add a quirk to the suspend code for various HP laptop models which would run the appropriate kernel function to power off (during suspend) and hence on (during resume) the amplifier for internal speakers. I suspect (but have not confirmed) that that quirk went missing between 8.04 LTS and 10.04 LTS; based on comments in #15 it seems to have been reintroduced between 9.04 and 9.10. FTR, I have found that hibernating the laptop (ie, out to disk, full power off), is sufficient to reset the internal amplifier state and make the internal speakers work again until the next suspend-to-RAM. IIRC from #15 the issue seemed to be that the internal amplifier power up code didn't get run unless it had been explicitly powered down. (And unfortunately it seems on other laptops it never got powered up if it got powered down, hence the patch which caused the problem.) Ewen -- [LUCID] hp compaq nc6220 no sound after resume Lucid Lynx https://bugs.launchpad.net/bugs/598242 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
patch -r (r == reverse) will unapply a patch. In this case given there's only one line changed it's actually easier just to edit the file in a text editor and uncomment the line that was commented out. If you're new to linux you may find the rest of the steps challenging too, and might be better waiting for the next Ubuntu release (Hardy Heron) which should have the fix included. It's due to be released within about 6 weeks I believe. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Tested with Hardy Alpha 4 (x86 Desktop). The Gnome configuration (apps -gnome-power-manager-timeout) still stores the difference between the screen saver time and the power management time, as in Gutsy. However I wasn't able to trigger the behaviour of the X11 DPMS off timeout being set to a non-zero amount even in half a dozen suspend-to-ram/resume cycles. So either the bug does not exist in Hardy, or it's much harder to trigger, or perhaps its difficult to trigger resuming from a Live CD boot. (It did seem that the resume in Hardy is noticeably faster, even off a Live CD, than in Gutsy, which I guess might change the circumstances of any race condition.) At this stage I think it's probably safe to assume that the issue is resolved in Hardy. (And I planned to upgrade to Hardy anyway, once it's released.) Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I think I've figured out how to trigger it. The computer in question is a laptop, with an external CRT connected via a docking station some of the time -- and all the times the DPMS Off: value has been incorrectly set, the laptop has been docked with the CRT connected. In order to trigger it I seem to need to: - boot up docked, with the CRT on - suspend to RAM - turn off the CRT - unsuspend (which is hit the power button in the case of this laptop) - while unsuspending, turn on the CRT (at the right time) In that situation I get: DPMS (Energy Star): Standby: 0Suspend: 0Off: 60 DPMS is Enabled Monitor is On or: DPMS (Energy Star): Standby: 0Suspend: 0Off: 300 DPMS is Enabled Monitor is On with the Off: time being set to the difference between the Power Mangement time and the Screensaver time. And if that time is non-zero, then playing with the adjusters seems to set the Off: time to the difference between the two (which definitely seems to be the wrong behaviour to me). So there appears to be two things going on: - there's something in Gnome (presumably Power Management) which is incorrectly setting the DPMS Off time to the difference between the Power Management off time and the Screensaver time (possibly when it notices a non-zero Off: time -- but irrespective, it's still doing the wrong thing: if it's going to set it, it should be to the total Power Management off time, or 0) - there's a race condition between the CRT waking up and the DPMS being reset to zero (possibly by some other power management program or task), where the DPMS setting doesn't stick until the CRT is ready to accept it (for which the fix is presumably to have the power management reapply the setting a little while, eg, 30 seconds, after either (a) unsuspend, or (b) the arrival of a new monitor. It appears once it becomes a non-zero value it's difficult to get the reset to 0 behaviour back; I did manage it with one suspend (powering on the CRT a little earlier in the unsuspend), but other attempts still didn't reset it to zero (including ensuring the CRT was fully powered on before unsuspending). In case it matters, the laptop is a HP NC6220, which has Intel integrated graphics (Intel 915GM), with a HP docking station, and a Viewsonic E70 CRT connected to it. Anyway it seems to me that if the Gnome power manager is going to manage the display power off itself, it should probably be explicitly resetting the X DPMS Off: time (and others) to 0, and definitely never setting it to the difference between the screensaver time and the Power Management screen off time. That seems to be the core bug. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Resetting status to New since there is now (hopefully) a way for others to reproduce it. ** Changed in: gnome-power-manager (Ubuntu) Status: Invalid = New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
I've just attempted to reproduce it now, with the same results as you (ie, the DPMS off time isn't being set as it was previously). I wondered whether it had something to do with either s2ram, or adding a monitor on resume (eg, docking with an external monitor) but neither of those seem to be triggering it now. I'll keep an eye out for it happening again in the next couple of weeks (it's pretty obvious as the monitor starts turning off pretty soon after I stop typing), and if it does happen try to figure out a more precise sequence to get it into that situation. If I don't see it again, perhaps it got resolved by a recent update. Thanks for trying to reproduce it. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
lspci -vvnn on HP NC6220 laptop attached, as requested. ** Attachment added: lspci -vvnn on HP NC6220 http://launchpadlibrarian.net/11928656/hp-nc6220-lspci-vvnn.txt -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System-Preferences-Power Management slider for Put display to sleep when inactive for shows values that start with the value set in System-Preferences-Screensaver slider for Regard the computer as idle after, and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be - set to is 8 minutes. + set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of 13 minutes, the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of 14 minutes the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS power off time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as 13 minutes. And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System-Preferences-Power Management slider for Put display to sleep when inactive for shows values that start with the value set in System-Preferences-Screensaver slider for Regard the computer as idle after, and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 9 minutes (8+1 minutes). However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of 13 minutes, the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of 14 minutes the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS power off time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the
[Bug 59589] Re: display sleep time - why 11 minutes
I suspect the 11 minutes minimum is coming from your system-preferences-screensaver being set to 11 minutes; the figure reported in the gnome power manager dialog seems to be offset by the screensaver amount (even though it doesn't seem to be implemented like that); I've reported a separate bug about this disparity between the UI and what actually happens: https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/190537 For now the best work around I can find is to set the gnome power manager display off timeout to be sufficiently large that the difference between that timeout and the screensaver timeout is the power off time that I actually want. Ewen -- display sleep time - why 11 minutes https://bugs.launchpad.net/bugs/59589 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] [NEW] [Gutsy] Display sleep sets wrong DPMS off time
Public bug reported: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System-Preferences-Power Management slider for Put display to sleep when inactive for shows values that start with the value set in System-Preferences-Screensaver slider for Regard the computer as idle after, and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of 13 minutes, the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of 14 minutes the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS power off time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as 13 minutes. And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a DPMS off time of 0 seconds, which happens to display the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen ** Affects: gnome-power-manager (Ubuntu) Importance: Undecided Status: New -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
Attached screenshot showing: - Screen Saver preference time of 8 minutes (480 seconds) - Power Manager display off time of 14 minutes (840 seconds) - gnome configuration apps-gnome-power-manager-timeout-sleep_display_ac value of 6 minutes (360 seconds; 14 minutes - 8 minutes = 6 minutes) - X DPMS information showing an off time of 360 seconds (6 minutes) Computer is on AC power at present. The values are live adjustable, and updating the slider in the power manager UI will result in new values being saved/set with the offset described above. Ewen ** Attachment added: Example of DPMS off time being difference between power-manager off time and screensaver time http://launchpadlibrarian.net/11849522/gnome-power-manager-dpms-time-incorrect.pngScreenshot.png -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 190537] Re: [Gutsy] Display sleep sets wrong DPMS off time
** Description changed: Binary package hint: gnome-power-manager In Ubuntu Gutsy (7.10) with gnome-power-manager (2.20.0-0ubuntu6), the System-Preferences-Power Management slider for Put display to sleep when inactive for shows values that start with the value set in System-Preferences-Screensaver slider for Regard the computer as idle after, and go upwards from there. Eg, if the Screensaver figure is set to 8 minutes, the minimum that the Power Manager display sleep can be set to is 8 minutes. However the value that is stored in the gnome configuration does not have this offset (eg, with the screensaver figure of 8 minutes, a power management display off figure of 13 minutes, the value stored in the gnome configuration will be 300 seconds (ie, 5 minutes). With a power management display off figure of 14 minutes the value stored will be 360 seconds (ie, 6 minutes). The value from the gnome configuration is then applied as an X DPMS power off time, eg 300 seconds as the display time off. The result is that the monitor will then turn off after 5 minutes (300 seconds), even though the gnome power management display off time is reported through the user interface as 13 minutes. And thus the monitor turns off even before the screen saver kicks in, and much earlier than it was set to do so. The only combination that actually works sanely is to set both timeouts to the same value (0 minutes difference), which results in a - DPMS off time of 0 seconds, which happens to display the automatic X + DPMS off time of 0 seconds, which happens to disable the automatic X server DPMS off time (leaving gnome power manager to do its own thing). This effect (idle time shown = screen saver time + power manager time; from https://bugs.launchpad.net/ubuntu/+source/gnome-power- manager/+bug/135813/comments/5) would appear to explain this bug: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/59589 too (ie, why the value cannot be set below 11 minutes -- they presumably have a screensaver time of 11 minutes). Obviously I expect that the time specified in gnome power manager to power off the display will be the time in reality, not some arbitrarily shorter time. (I first noticed this with a screen saver time of 8 minutes, and a display off time of 9 minutes -- which caused the screen to power down after 1 minute of inactivity.) There are various ways this could be fixed to work sanely: - have gnome-power-manager not set the X server DPMS time and manage everything itself, counting from when the screen saver kicks in - have gnome-power-manager set the X server DPMS time to the value stored plus the screen saver timeout (so the overall time is consistent with what is shown in the preferences dialog) - have the preferences dialog store the value shown into the gnome preferences (including the amount that is attributed to the screensaver timeout, eg the full 13 minutes == 780 seconds) so that the value can be set directly into the X server DPMS and will give the correct timeout - decouple the power manager and screen saver timeouts again, so that the power manager screen off time can be set from 1 minute upwards. This would also allow having the screen powered down before the screen is locked, which can be useful if one is doing something else nearby but wants to save power (eg, a power manager off time of 3 minutes, and a lock time of 5 minutes, would power the display down pretty rapidly but allow waking it with a keypress without having to type in a password). This would just require changing the power manager preferences UI to accurately report the figure it's setting into the gnome preferences. Ewen -- [Gutsy] Display sleep sets wrong DPMS off time https://bugs.launchpad.net/bugs/190537 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
This might seem really obvious, but you did make (the opposite of) change listed in this comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 before you built the modules, right? Ie, you have to uncomment the line: pci_set_power_state(pci, pci_choose_state(pci, state)); In the ..._suspend() function. (The change in that patch commented out the line, which is a call to control the power to the sound card -- the HP NC6220 appears to need that call for audio to work on resume.) If you just rebuild without making that change, you'll get exactly what shipped with Ubuntu Gutsy, which as we know doesn't work. If you didn't make that change, try making that change, rebuilding (run the make ... lines again and make sure it compiles sound/pci/intel8x0.c and the *.ko files again, then copy them back over and restart. (My list of things to do wasn't intended to be an exhaustive list of all the steps required, just to indicate that it wasn't necessary to fully rebuild the kernel -- which takes a long time -- only the modules.) Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
I can confirm that on a HP NC6220 after resume with the -generic Ubuntu Gutsy kernel (2.6.22-14.47) the internal speakers are mute (but playback to external speakers and/or headphones is fine). After reverting the patch mentioned earlier in this bug, at comment: https://bugs.launchpad.net/ubuntu/+source/linux- source-2.6.22/+bug/15/comments/1 the internal speakers work after suspend to RAM and resume (in fact the sound continues playing even before the screen is reset). Looking at the line that is re-enabled by reverting that patch, it appears that on the HP NC6220 the internal amplifier does not get powered on again unless the sound card is powered off at suspend time (without that it appears that whatever turns the power to the amplifier back on again doesn't get run when the sound card is powered up again in the resume code). Given the comment in the patch mentioned above I guess in some other laptops the power on code doesn't work at all, so if it's powered down it never gets powered up. So the best fix is probably to put that particular power down line under the control of a kernel module option, so on the HP NC6220, etc, the card can be properly powered down at suspend so it powers up fully at resume, but on other laptops where that causes problems the power down can be skipped. FTR (in case it helps someone else) it appears to be sufficient (after installing the packages needed to compile a kernel) to do: apt-get source linux-image-2.6.22-14-generic cd linux-source-2.6.22-2.6.22 cp /boot/config-`uname -r` .config make oldconfig make sound/pci/snd-intel8x0.ko make sound/pci/snd-intel8x0m.ko # Make a backup of the existing sound modules if desired then... cp -p sound/pci/snd*ko /lib/modules/`uname -r`/kernel/sound/pci/ and then reboot to use the new modules. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 151111] Re: No Sound after Resume on some HP Laptops
Ah, yes, I'd forgotten I'd done that: mkdir .tmp_versions (somewhere after cd'ing into the directory with the source and before running make) After you run the mkdir you can just run make again, and it'll continue from where it left off. Apologies for the confusion. Ewen -- No Sound after Resume on some HP Laptops https://bugs.launchpad.net/bugs/15 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I can confirm that the Firefox package 1.5.dfsg+1.5.0.9-0ubuntu0.6.06.1 no longer crashes when presented with the Mailman admin form where there is a saved password. Thanks for pushing out updated packages. Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Patch for Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've now modified the patch from Mozilla Bugzilla (linked earlier in this bug) to apply to Firefox 1.5.0.9 (as shipped with Ubuntu) and recompiled the Firefox package with the patch (which takes about 2 hours, and 1GB of disk space), and appear to have a non-broken version of Firefox that is able to handled saved passwords on forms with and without usernames (ie, properly fill them in, both Mailman's admin screen and Launchpad's login form seemed to work). The modified patch is attached. Perhaps someone at Ubuntu could verify that this patch makes sense, and if so apply it and rebuild the Firefox security update. (I'd offer to make my binary available for others to test, but as far as I can tell Firefox trademark restrictions prevent anyone distributing a non- authorised build, even if it's supposed to be more stable than the one it replaces.) Ewen ** Attachment added: Firefox 1.5.0.9 password only forms fix http://librarian.launchpad.net/5859913/firefox-1.5.0.9-saved-passwords-password-only.diff -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin
I've retitled the bug to make it clearer that (a) it's a regression, (b) it only affects Ubuntu Dapper, and (c) it's only the Firefox 1.5.0.9 security update which is affected. At this point I don't think we need any more it doesn't crash for me, but I'm using some other browser version reports. It's pretty clearly a flaw introduced with the security update and as far as I can tell affects everyone using Ubuntu Dapper with Firefox 1.5.0.9 and an affected webpage (password only form with saved passwords). Ewens ** Summary changed: - Saved passwords causes crash with Mailman admin (1.5.x) + Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin ** Description changed: Binary package hint: firefox + + [Edit: NOTE: This is a _regression_ in Firefox 1.5.0.9, released as a + security update for Ubuntu Dapper. Functionality that used to work + perfectly now causes the browser to crash hard. The problem appears to + be widely reproduced with the only people unable to reproduce it being + those using some other browser version.] The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the fix chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen -- Dapper: Regression: Firefox 1.5.0.9: Saved passwords causes crash with Mailman admin https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
In the hope that this will bring the bug to the firefox/security maintainers attention, I've changed the status to confirmed given (a) the number of bugs which have been marked as a duplicate of this bug, and (b) that several people have reported they can reproduce the bug. It would be nice to have some indication from the Firefox maintainer and/or the Ubuntu security folks as to when this regression introduced with the Dapper 1.5.0.9 package might be looked at. Ewen ** Changed in: firefox (Ubuntu) Status: Unconfirmed = Confirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
As suggested by Peter Cherriman (https://launchpad.net/~pjcherriman) in comment: https://launchpad.net/ubuntu/+source/firefox/+bug/77859/comments/3 I've installed the firefox-dbg package (ie, debug symbols), and regenerated the core dump and run gdb over it. Like him I see: nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 as the topmost item on the stack prior to the signal handler being invoked, so I too suspect that aElement=0x0 is somehow involved in the segmentation fault. Full gdb backtrace follows. Ewen -=- cut here -=- [EMAIL PROTECTED]:/var/tmp$ ulimit -c unlimited [EMAIL PROTECTED]:/var/tmp$ firefox [1] 26943 [EMAIL PROTECTED]:/var/tmp$ [1]+ Segmentation fault (core dumped) firefox [EMAIL PROTECTED]:/var/tmp$ ls -l core* -rw--- 1 ewen ewen 55312384 2007-01-06 12:38 core.26943 [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.26943 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...Using host libthread_db library / lib/tls/i686/cmov/libthread_db.so.1. Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/firefox/libmozjs.so...Reading symbols from /usr/li b/debug/usr/lib/firefox/libmozjs.so...done. done. [] Loaded symbols for /usr/lib/firefox/components/libnkgnomevfs.so #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7d8d790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in nsProfileLock::FatalSignalHandler (signo=-1210510412) at nsProfileLock.cpp:206 #3 signal handler called #4 0xb67e65cc in nsPasswordManager::AttachToInput (this=0x89f6368, aElement=0x0) at nsPasswordManager.cpp:1962 #5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368, aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsPasswordManager.cpp:948 #6 0xb5dd3e62 in nsDocLoader::FireOnStateChange (this=0x8205c88, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1210 #7 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x835a5b8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #8 0xb5dd3ea0 in nsDocLoader::FireOnStateChange (this=0x86a6cd8, aProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0) at nsDocLoader.cpp:1217 #9 0xb5dd423b in nsDocLoader::doStopDocumentLoad (this=0x86a6cd8, request=0x86939b4, aStatus=0) at nsDocLoader.cpp:833 #10 0xb5dd4313 in nsDocLoader::DocLoaderIsEmpty (this=0x86a6cd8) at nsDocLoader.cpp:739 #11 0xb5dd45df in nsDocLoader::OnStopRequest (this=0x86a6cd8, aRequest=0x890d118, aCtxt=0x0, aStatus=0) at nsDocLoader.cpp:662 #12 0xb723ae35 in nsLoadGroup::RemoveRequest (this=0x86a6740, request=0x890d118, ctxt=0x0, aStatus=0) at nsLoadGroup.cpp:732 #13 0xb56c0c6e in nsDocument::UnblockOnload (this=0x88ff600) at nsDocument.cpp:5015 #14 0xb56e256a in DestroyImagePLEvent (aEvent=0x8a09438) at nsImageLoadingContent.cpp:668 #15 0xb7e40351 in PL_DestroyEvent (self=0x8a09438) at plevent.c:727 #16 0xb7e403bd in PL_HandleEvent (self=0x8a09438) at plevent.c:699 #17 0xb7e40b2e in PL_ProcessPendingEvents (self=0x80d3758) at plevent.c:623 #18 0xb7e41ed0 in nsEventQueueImpl::ProcessPendingEvents (this=0x80d3710) at nsEventQueue.cpp:417 #19 0xb68a3449 in event_processor_callback (source=0x8312d28, condition=G_IO_IN, data=0x0) at nsAppShell.cpp:67 #20 0xb77bc52c in g_vasprintf () from /usr/lib/libglib-2.0.so.0 #21 0xb77958d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #22 0xb7798996 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #23 0xb7798cb8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #24 0xb7bc7765 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb68a38da in nsAppShell::Run (this=0x814e778) at nsAppShell.cpp:139 #26 0xb67c33d2 in nsAppStartup::Run (this=0x814e738) at nsAppStartup.cpp:150 #27 0x0804f321 in XRE_main (argc=3, argv=0xbf82acf4, aAppData=0x80595e0) at nsAppRunner.cpp:2380 #28 0x0804abe4 in main (argc=0, argv=0x0) at nsBrowserApp.cpp:61 #29 0xb752bea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #30 0x0804ab31 in _start () at ../sysdeps/i386/elf/start.S:119 (gdb) -=- cut here -=- -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Source for affected function that is segfaulting:
void
nsPasswordManager::AttachToInput(nsIDOMHTMLInputElement* aElement)
{
nsCOMPtrnsIDOMEventTarget targ = do_QueryInterface(aElement);
nsIDOMEventListener* listener = NS_STATIC_CAST(nsIDOMFocusListener*, this);
targ-AddEventListener(NS_LITERAL_STRING(blur), listener, PR_FALSE);
targ-AddEventListener(NS_LITERAL_STRING(DOMAutoComplete), listener,
PR_FALSE);
mAutoCompleteInputs.Put(aElement, 1);
}
(1956-1966 in
firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp)
The affected line, 1962, is:
targ-AddEventListener(NS_LITERAL_STRING(blur), listener, PR_FALSE);
and appears to be segfaulting because the raw pointer inside targ is
0x0:
(gdb) print targ
$1 = {nsCOMPtr_base = {mRawPtr = 0x0}, No data fields}
I _think_ that the raw pointer inside targ is null because atElement is null,
but there's too much magic in the ns smart pointers to trace through without
ever having seen the code before.
Working back up the stack, the caller is:
-=- cut here -=-
(gdb) up
#5 0xb67e7724 in nsPasswordManager::OnStateChange (this=0x89f6368,
aWebProgress=0x86a6cec, aRequest=0x86939b4, aStateFlags=131088, aStatus=0)
at nsPasswordManager.cpp:948
948 AttachToInput(userField);
(gdb) print userField
$6 = {nsCOMPtr_base = {mRawPtr = 0x0}, No data fields}
(gdb)
-=- cut here -=-
where the function contains the inline comment:
-=- cut here -=-
// We can auto-prefill the username and password if there is only
// one stored login that matches the username and password field names
// on the form in question. Note that we only need to worry about a
// single login per form.
-=- cut here -=-
All of which tends to confirm my impression that the problem is prefilling in a
save password on forms which have only a password field and no username field,
Whatever changed in the code appears to no longer properly handle the situation
where there is no username field and instead seems to assume that there'll be a
username field to attach to if it finds a password field When it tries to
attach to a non-existantant username field, thus dereferencing the null, it
crashes.
Ewen
--
Firefox: saved passwords causes crash with Mailman admin page
https://launchpad.net/bugs/77859
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
I managed to find the source to firefox-1.5.dfsg+1.5.0.8 on a mirror
(http://mirror.xmu.edu.cn/archive.ubuntu.com/ubuntu/pool/main/f/firefox/;
it's already expired out of security.ubuntu.com and archive.ubuntu.com).
Diff between firefox-1.5.dfsg+1.5.0.8 and firefox-1.5.dfsg+1.5.0.9
reveals that a guard on userField being non-null was removed between
those two versions, viz:
-=- cut here -=-
@@ -941,20 +945,20 @@
}
if (firstMatch !attachedToInput) {
- nsAutoString buffer;
-
- if (userField) {
+ AttachToInput(userField);
+
+ if (prefillForm) {
+nsAutoString buffer;
if (NS_FAILED(DecryptData(firstMatch-userValue, buffer)))
goto done;
-=- cut here -=-
(Full diff of that file below.)
So since it appears to be fatal to call AttachToInput(NULL), it appears
that the function has been deliberately changed to cause Firefox to
crash when faced with a presaved form which has no username field. This
seems to be undesirable. At very worst it should refuse to fill in the
form and continue running; ideally it would continue the previous
Firefox behaviour and fill in the form without fuss.
There's nothing in the comments or changelog to explain why the guard on
userField being non-null was removed. The entire changelog for .8 to .9
is:
-=- cut here -=-
firefox (1.5.dfsg+1.5.0.9-0ubuntu0.6.06) dapper-security; urgency=low
* New upstream security update:
- CVE-2006-6504, MFSA 2006-73: SVG Processing Remote Code Execution.
- CVE-2006-6503, MFSA 2006-72: XSS by setting img.src to javascript: URI.
- CVE-2006-6502, MFSA 2006-71: LiveConnect crash finalizing JS objects.
- CVE-2006-6501, MFSA 2006-70: Privilege escallation using watch point.
- CVE-2006-6497, CVE-2006-6498, CVE-2006-6499, MFSA 2006-68: Crashes
with evidence of memory corruption.
-- Kees Cook [EMAIL PROTECTED] Tue, 2 Jan 2007 11:23:28 -0800
-=- cut here -=-
None of the CVE or MFSA documents referenced talk about the password
manager or saved password exploits or appear to explain why this code
was changed. Given other security discussion I'm aware of I assume it's
part of an attempt to avoid the recently publicised password stealing
attack through user-created forms being pre-filled.
The list appears to come from here:
http://www.mozilla.org/projects/security/known-
vulnerabilities.html#firefox1.5.0.9
which is referenced from here:
http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html
which is the upstream announcement of 1.5.0.9.
Most of the change in nsPasswordManager.cpp appears to have come from
upstream (comparing diffs with and without the ubuntu dapper patches).
However upstream 1.5.0.8 upstream also didn't have the guard on
userField being non-NULL. That guard was being added by the ubuntu
dapper patch in 1.5.0.8, but is not being added in 1.5.0.9.
In particular we seem to have lost this patch:
-=- cut here -=-
* toolkit/components/passwordmgr/base/nsPasswordManager.cpp: Take patch
from bz#235336 as suggested by Ian Jackson to allow password manager
to work with sites that only have a password field, no username.
-- Eric Dorland [EMAIL PROTECTED] Mon, 6 Feb 2006 23:10:29 -0500
-=- cut here -=-
I'm not sure what bz#235336 is or where it can be found, but I
strongly suspect that it includes the guard on userField being non-null.
So it appears that a combination of an upstream change and dropping a patch
that allowed password manager to work with password-only forms has caused
this crash.
It also appears to me that upstream will have this bug (crash with saved
passwords on forms with only a password field) if I'm reading their code
correctly.
Any chance we can have this bz#235336 patch reapplied and/or the guard
on userField back again, so password manager works with password only forms and
firefox doesn't crash?
Ewen
-=- full 1.5.0.8 to 1.5.0.9 diff for nsPasswordManager.cpp -=-
[EMAIL PROTECTED]:/var/tmp/ubuntu-dapper-firefox$ diff -u
firefox-1.5.dfsg+1.5.0.{8,9}/toolkit/components/passwordmgr/base/nsPasswordManager.cpp
---
firefox-1.5.dfsg+1.5.0.8/toolkit/components/passwordmgr/base/nsPasswordManager.cpp
2007-01-06 13:45:37.0 +1300
+++
firefox-1.5.dfsg+1.5.0.9/toolkit/components/passwordmgr/base/nsPasswordManager.cpp
2007-01-06 12:53:22.0 +1300
@@ -815,6 +815,10 @@
PRUint32 formCount;
forms-GetLength(formCount);
+
+ // check to see if we should formfill. failure is non-fatal
+ PRBool prefillForm = PR_TRUE;
+ mPrefBranch-GetBoolPref(prefillForms, prefillForm);
// We can auto-prefill the username and password if there is only
// one stored login that matches the username and password field names
@@ -907,7 +911,7 @@
continue;
}
- if (!oldUserValue.IsEmpty()) {
+ if (!oldUserValue.IsEmpty() prefillForm) {
// The page has prefilled a username.
// If it matches any of our saved usernames, prefill the password
// for that
[Bug 77859] Firefox: Regression: saved passwords: password only forms crash firefox (patch lost)
Found the patch that got lost: Mozilla Bugzilla 235336: https://bugzilla.mozilla.org/show_bug.cgi?query_format=specificorder=relevance+descbug_status=__open__id=235336 (was obvious once I guessed that bz == Bugzilla not Baz/Bazzar or similar.) And the relevant patch: https://bugzilla.mozilla.org/attachment.cgi?id=185577 referred to does indeed add the guard on userField being non-NULL. Please apply, modified as necessary to fit 1.5.0.9. Ewen -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Firefox: saved passwords causes crash with Mailman admin page
Public bug reported: Binary package hint: firefox The latest security update for Firefox for Ubuntu Dapper (6.06), version 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, now causes Firefox to crash repeatedly when using a saved password field on a Mailman admin login screen. This did not happen with the previous version (1.5.dfsg+1.5.0.8-0ubuntu0.6.06) or any previous version that I can recall. Other forms with saved passwords may also be affected (I initially thought that it was all saved forms, but it seems the one for launchpad.net isn't affected -- curious). Ubuntu Version: Dapper Drake (6.06) Firefox Version: 1.5.dfsg+1.5.0.9-0ubuntu0.6.06, Reproducable: always How to reproduce: 1. Stop Firefox 2. Remove ~/.mozilla/firefox/PROFILE/signons.txt 3. Start Firefox 4. Go to http://somelistserver/mailman/admindb/mailman 5. Log in 6. Choose to allow Firefox to save the password 7. Observe Firefox crashes 8. Restart Firefox 9. Go back to http://somelistserver/mailman/admindb/mailman 10. Observe Firefox crashes again without displaying the page 11. Go back to step 2 and repeat. 12. Go back to step 2 and repeat choosing NOT to save the password at step 6 and observe Firefox doesn't crash Desired behaviour: As per previous version, should fill in saved password for the form and not crash. Other notes: It doesn't appear necessary for the password to actually be correct; just that it be saved. The crash on visiting the page with a saved password appears to happen aroun the time that the saved password might be pre-filled. Completely removing the saved passwords and starting again doesn't seem to help; as soon as the password is saved the problem reappears. Removing the firefox profile and starting again also doesn't seem to help; again as soon as the password is saved the problem reappears. The only thing I can see which is noticably different between the Mailman login page and, eg, the launchpad.net login page, in terms of saved passwords, is that the Mailman page is password-only, whereas the launchpad.net has an email address as well as the password. Possibly the bug is somehow related to the form being password-only. This behaviour is new with the security update for Ubuntu Dapper which came out this morning. I've used the saved password feature with many previous versions of Firefox without any problems. Knowing the issues which have been reported with Firefox recently, including a password stealing attack, I'd guess that there is a bug in the fix chosen to try to defeat that password stealing attack. Finally, for what little it seems to be worth, a backtrace of the coredump: [EMAIL PROTECTED]:/var/tmp$ gdb /usr/lib/firefox/firefox-bin core.10049 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (no debugging symbols found) Core was generated by `/usr/lib/firefox/firefox-bin -a firefox'. Program terminated with signal 11, Segmentation fault. [] #0 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7e56790 in raise () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08055e0b in ?? () #3 0x000b in ?? () #4 0xbfaf0e8c in ?? () #5 0x in ?? () (gdb) Ewen ** Affects: firefox (Ubuntu) Importance: Undecided Status: Unconfirmed -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 77859] Re: Firefox: saved passwords causes crash with Mailman admin page
Issolated test case: http://www.naos.co.nz/tmp/ubuntu/firefox/mailman-signon-page.html Steps to reproduce is slightly different here, I think because there's no real form processing behind it. To reproduce: 1. Go to URL 2Enter some string to be the password, eg test (it doens't matter, just needs something) 3. Choose to remember the password 4. Observe success message 5. Go back to URL (eg, click on the link in the success page) 6. Observe browser crashes 7. Restart firefox 8. Go to URL 9. Observe browser crashes 10. Remove ~/.mozilla/firefox/PROFILE/signons.txt 11. Start firefox 12. Go to URL 13. Observe browser doesn't crash 14. Repeat from 2 Test case (stripped down version of the Mailman admin page) is attached. The success page is just a stub HTML page with a link to this bug and back to the test case for convenience. Something like the launchpad.net signon form can serve as an example that doesn't crash. Ewen ** Attachment added: Issolated test case (extracted from Mailman admin signon form) http://librarian.launchpad.net/5593238/mailman-signon-page.html -- Firefox: saved passwords causes crash with Mailman admin page https://launchpad.net/bugs/77859 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
