clock-applet continually crashing

thanks for the report, waiting for the stacktrace then and setting the bug to incomplete.

The stack trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2fbeb70 (LWP 12057)]
__strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:39
39 ../sysdeps/i386/i686/multiarch/../strcmp.S: No such file or directory.
 in ../sysdeps/i386/i686/multiarch/../strcmp.S
(gdb) where
#0 __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:39
#1 0x04c2f252 in _run (self=0x98e5788, pac=0x983f2f0, url=0x990e988)
    at pacrunner_webkit.c:197
#2 0x00dafb52 in px_proxy_factory_get_proxies (self=0x984ee80,
    url=0x98e82d8 "http://weather.noaa.gov/cgi-bin/mgetmetar.pl?cccc=CYGK")
    at proxy.c:401
#3 0x00a9fdb2 in ?? () from /usr/lib/libsoup-gnome-2.4.so.1
#4 0x00aa0199 in ?? () from /usr/lib/libsoup-gnome-2.4.so.1
#5 0x007633d4 in g_thread_pool_thread_proxy (data=0x9854df8)
    at /build/buildd/glib2.0-2.26.0/glib/gthreadpool.c:319
#6 0x0076148f in g_thread_create_proxy (data=0x9906bb0)
    at /build/buildd/glib2.0-2.26.0/glib/gthread.c:1897
#7 0x00e39cc9 in start_thread (arg=0xb2fbeb70) at pthread_create.c:304
#8 0x009d56ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

So this looks like a bug in webkit, not gnome-panel.

Pedro,

I supplied the stack trace as promised. Can you please update this ticket?

I'm also affected by this bug, which I already noticed in Ubuntu 10.04 and is still present in 10.10.

When located behind a firewall and having an automatic proxy script defined in System --> Preferences --> Network proxy, the bug is 100% reproductible by following this simple procedure:
- add a clock applet on a gnome-panel;
- add a city in its configuration (Click on the date/time --> Locations --> Edit --> Add --> chose any location --> OK);
- when clicking on OK, the applet always crashes immediately with an error message "Clock has quit unexpectedly ... " and 2 buttons "Don't Reload" and "Reload";
- if I click "Reload", the applet reloads OK but crashes again exactly 52 seconds later (perfectly reproductible);
- this cycle of reloads and crashes after 52 seconds can be repeated for a long time; the applet never runs for more then 52 seconds before crashing.

But: if I declare a manual proxy or put the same machine on a network where no proxy is needed, the clock applet never crashes.

Nov 2 16:35:47 SEMTEST-DEV-0005 kernel: [ 54.263621] clock-applet[1637]: segfault at 0 ip 009094ab sp b2594fdc error 4 in libc-2.12.1.so[7ed000+157000]
Nov 2 16:36:44 SEMTEST-DEV-0005 kernel: [ 111.669188] clock-applet[1664]: segfault at 0 ip 0102a4ab sp b3bfdfdc error 4 in libc-2.12.1.so[f0e000+157000]
Nov 2 16:37:38 SEMTEST-DEV-0005 kernel: [ 165.686836] clock-applet[1683]: segfault at ffffffc9 ip b65df95f sp b3c24f70 error 4 in libwebkit-1.0.so.2.17.6[b5db4000+d7f000]
Nov 2 16:38:30 SEMTEST-DEV-0005 kernel: [ 217.686054] clock-applet[1702]: segfault at 0 ip 0104a4ab sp b3bfdfdc error 4 in libc-2.12.1.so[f2e000+157000]
Nov 2 16:39:22 SEMTEST-DEV-0005 kernel: [ 269.686319] clock-applet[1721]: segfault at ffffffc9 ip 0704995f sp b4b7af70 error 4 in libwebkit-1.0.so.2.17.6[681e000+d7f000]
Nov 2 16:40:18 SEMTEST-DEV-0005 kernel: [ 325.684750] clock-applet[1740]: segfault at 0 ip 00a784ab sp b3bfdfdc error 4 in libc-2.12.1.so[95c000+157000]
Nov 2 16:41:10 SEMTEST-DEV-0005 kernel: [ 377.676607] clock-applet[1803]: segfault at c ip b64ec95f sp b3be7f70 error 4 in libwebkit-1.0.so.2.17.6[b5cc1000+d7f000]
Nov 2 16:42:04 SEMTEST-DEV-0005 kernel: [ 431.670838] clock-applet[1826]: segfault at 0 ip 068834ab sp b3bfdfdc error 4 in libc-2.12.1.so[6767000+157000]
Nov 2 16:42:57 SEMTEST-DEV-0005 kernel: [ 484.687529] clock-applet[1846]: segfault at ffffffc9 ip b66df95f sp b3d27f70 error 4 in libwebkit-1.0.so.2.17.6[b5eb4000+d7f000]
Nov 2 16:43:49 SEMTEST-DEV-0005 kernel: [ 536.686845] clock-applet[1865]: segfault at ffffffc9 ip 0390395f sp b4c27f70 error 4 in libwebkit-1.0.so.2.17.6[30d8000+d7f000]
Nov 2 16:44:41 SEMTEST-DEV-0005 kernel: [ 588.687246] clock-applet[1884]: segfault at ffffffc9 ip b65ec95f sp b3c98f70 error 4 in libwebkit-1.0.so.2.17.6[b5dc1000+d7f000]
Nov 2 16:45:33 SEMTEST-DEV-0005 kernel: [ 640.686276] clock-applet[1905]: segfault at 8 ip 04dd9962 sp b4afdf70 error 4 in libwebkit-1.0.so.2.17.6[45ae000+d7f000]
Nov 2 16:46:26 SEMTEST-DEV-0005 kernel: [ 693.687959] clock-applet[1928]: segfault at ffffffc9 ip b65ec95f sp b3c98f70 error 4 in libwebkit-1.0.so.2.17.6[b5dc1000+d7f000]
Nov 2 16:47:19 SEMTEST-DEV-0005 kernel: [ 746.685149] clock-applet[1947]: segfault at 0 ip 00eb04ab sp b3bfdfdc error 4 in libc-2.12.1.so[d94000+157000]
Nov 2 16:48:11 SEMTEST-DEV-0005 kernel: [ 798.677651] clock-applet[1966]: segfault at ffffffc9 ip 0410c95f sp b4a26f70 error 4 in libwebkit-1.0.so.2.17.6[38e1000+d7f000]
Nov 2 16:49:04 SEMTEST-DEV-0005 kernel: [ 851.668458] clock-applet[1986]: segfault at ffffffc9 ip b64ec95f sp b3be7f70 error 4 in libwebkit-1.0.so.2.17.6[b5cc1000+d7f000]
Nov 2 16:49:56 SEMTEST-DEV-0005 kernel: [ 903.669603] clock-applet[2007]: segfault at ffffffc9 ip 04cb295f sp b4a89f70 error 4 in libwebkit-1.0.so.2.17.6[4487000+d7f000]

Sorry for the above text being put as a comment rather then an attachment; this is indeed the output of the command:
cat /var/log/messages | grep clock-applet

Pedro, you said in comment #2:

> thanks for the report, waiting for the stacktrace then and setting the bug to incomplete.

Not only did I attach the stacktrace, I also brought it to your attention subsequently. I did as I was asked. Now please do as you committed to doing. AFAIC, we had a verbal contract and you are not holding up your end of it. Too much of this crap happens in Ubuntu bugs. Developers get "bored" with bugs and just move on to something else and let open issues just fester.

Pedro,

NM. I've pushed and am working this bug upstream anyway since nothing is happening with it here. Hopefully it will be fixed there.

Upstream seems to be ignoring the bug report.

I think you need to either look into using a different JS engine for libproxy or abandon using libproxy. Either way, having applications continuing to crash due to the reliance on buggy and unmaintained software is not a workable situation.

This bug seems to have survived and made it into Natty now.

Will there be any effort at solving it at all?

This was a bug in libproxy, not webkit.

Per the upstream libproxy bug, I have confirmed that upgrading libproxy to 0.4.7 has fixed this problem.

Can we get an SRU (IIR-the-acronym-C) to update libproxy to 0.4.7 for Natty please?

The problem just randomly started occurring for me yesterday, though the time between crashes seems to be random, not every 52 seconds as mentioned earlier. I'm running on a relatively new install of Natty (perhaps six weeks old max) with libproxy version 0.3.1-2. Is there any supported way to upgrade like Brian mentioned?

This is still affecting Natty and presumably Ocelot (or whatever Natty+1 is) since libproxy 0.3.1 is simply broken.

This package badly needs updating to 0.4.7 to fix all of the crashing that's going on with it and PAC proxy configurations.

Hi, I also recently started using proxy auto configuration (PAC) script to configure my proxy setting in the new project environment. The crashing keeps happening until I connect to internet. After I am connected the reload button successfully restores clock and it works rock solid all day long.

On 11-09-20 02:54 AM, Aurius Bendikas wrote:
> Hi, I also recently started using proxy auto configuration (PAC) script
> to configure my proxy setting in the new project environment. The
> crashing keeps happening until I connect to internet. After I am
> connected the reload button successfully restores clock and it works
> rock solid all day long.

To be clear, this issue is not one of being connected or not. I am
connected 24x7 and the clock crashes continually until I upgrade
libproxy from it's aged 0.3.1 to currently maintained 0.4.7.

So, maintainer, is libproxy going to be updated or are we going to have
yet another release (an LTS in fact!) with a broken libproxy?

Hello? Why is this being ignored as yet another release (O<whatever it's called>) marches towards being yet another broken release?

This version is expired