FWIW, killall clock-applet just killed the clock applet. I did 'pkill gnome-panel' and the panel came back with the clock applet running.  

Fresh out of the box, clock-applet uses 1321m virtual, 77m resident, 12m shared.

Checked repeatability and long term behavior: I can confirm that it happens every time I restart the applet. 

The memory leak seems to be more-less constant over time: the resident set seems to increase at an aggregate rate of 60MB every hour, or about 1.5 GB/day.

I looked at the actual pattern of activity in the RSS size, and it is quite irregular: I see 40 MB jump then a 20 MB jump a minute later, then 30 minutes of no change, then 10 MB and another 10MB within a minute, followed by no activity for another 30 minutes, and a 40MB jump followed by 20 MB.

I attached gdb to the executable, breaking in malloc() and saw large allocations (20MB, see stack trace below). It seems that wireToDeviceEvent() from XExtInt.c does the following:
	
1511 ptr = (unsigned char*)&in[1] + in->buttons_len * 4;
1512	
1513 len = sizeDeviceEvent(in->buttons_len * 4, in->valuators_len * 4, ptr);
1514	
1515 cookie->data = ptr_lib = malloc(len);

and maybe sizeDeviceEvent calculates the size wrong?


#0  __GI___libc_malloc (bytes=20301328) at malloc.c:2848
#1  0x00000036e960936b in wireToDeviceEvent (cookie=0xe94568, in=0x135c610)
    at XExtInt.c:1515
#2  XInputWireToCookie (dpy=<optimized out>, cookie=0xe94568, event=0x135c610)
    at XExtInt.c:979
#3  0x00000036e1a456e5 in _XEnq (dpy=dpy@entry=0xdd3190, event=event@entry=
    0x135c610) at XlibInt.c:899
#4  0x00000036e1a42813 in handle_response (dpy=dpy@entry=0xdd3190, response=
    0x135c610, in_XReply=in_XReply@entry=0) at xcb_io.c:338
#5  0x00000036e1a43075 in _XEventsQueued (dpy=dpy@entry=0xdd3190, 
    mode=mode@entry=2) at xcb_io.c:363
#6  0x00000036e1a346bd in XPending (dpy=0xdd3190) at Pending.c:55
#7  0x00000036f9e4a898 in gdk_check_xpending (display=<optimized out>)
    at gdkeventsource.c:266
#8  gdk_event_source_check (source=0xdebe70) at gdkeventsource.c:297
#9  0x00000036e124782c in g_main_context_check (context=context@entry=
    0xdcd9e0, max_priority=2147483647, fds=fds@entry=0x1354350, 
    n_fds=n_fds@entry=6) at gmain.c:3169
#10 0x00000036e1247cc2 in g_main_context_iterate (context=0xdcd9e0, 
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at gmain.c:3287
#11 0x00000036e1248182 in g_main_loop_run (loop=0xf0cbd0) at gmain.c:3484
#12 0x00000036f938dd4d in gtk_main () at gtkmain.c:1160

On the other hand, I see that maybe the GDB display cannot be trusted, because of this other breakpoint stack trace:

#0  __GI___libc_malloc (bytes=139987882367488) at malloc.c:2848
#1  0x00000036e124d68f in g_malloc (n_bytes=n_bytes@entry=4096) at gmem.c:159
#2  0x00000036e52338cc in g_buffered_input_stream_set_buffer_size (stream=
    0x7f5178005a00 [GDataInputStream], size=4096) at gbufferedinputstream.c:241

Here __GI___libc_malloc seems to see some absurd allocation size but the malloc is called as

 mem = glib_mem_vtable.malloc (n_bytes);

and n_bytes is 4096. Maybe it's a typing error: __GI___libc_malloc expects size_t and n_bytes is long unsigned int (they both show sizeof(..) equal to 8 though...)

I changed the settings to show the date, and NOT show seconds, temperature and weather, and the memory is just 800MB after a day of running. 

Seriously, this memory leak needs fixing!

If someone could suggest a way to run valgrind on clock-applet I would like to try that---maybe it'll show where the memory goes. 

I killed it, and refused to restart it when the gnome-panel popped up a warning. Then I tried to run it from the commandline ('valgrind /usr/libexec/clock-applet') but that didn't work. There has to be a way to make gnome-panel invoke valgrind when running clock-applet--perhaps by changing the executable path in gnome preferences---but how would one see the resulting valgind output? 

By the way, the above caused the clock to disappear from the top panel, and I had to re-discover that Alt-rightclick is the secret combo for adding/moving/removing panel applets.

I don't know of a "good" way of doing this, but an evil hack to get this info might be to move /usr/libexec/clock-applet to /usr/libexec/the-real-clock-applet and replace /usr/libexec/clock-applet with a shell script that invokes:
  valgrind /usr/libexec/the-real-clock-applet

Not sure where the output would go, though.

(You might need to make an analogous move to the debuginfo also)

*** Bug 908003 has been marked as a duplicate of this bug. ***

I removed all locations (and turned off weather) and that seems to help.

Before that the applet was regularly clocking up (sorry!)
1.5GB+ of physical memory... (since it doesn't use much cpu
it took me a while to notice that clock-applet was the culprit
of my machine swapping so much of the time).

i also see this - it is especially bad if you enable the display of seconds.

my f19 workstation can run for about a week and a half then all the swap space is used up by clock-applet - ROFL

kill clock-applet and select reload at the pop-up - then you get most of your swap space back.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I see this with mate-panel clock too in F20.

$ ps lx | grep clock
0  1000  1908     1  20   0 2064484 29224 poll_s Sl  ?         53:23 /usr/libexec/mate-panel/clock-applet

(In reply to Jens Petersen from comment #13)
> I see this with mate-panel clock too in F20.

1. Pls, open a new report instead or re-opening old gnome-bugs, gnome-2 is dead.

2. As a fedora package maintainer, why you don't open  a report directly at upstream?
https://github.com/mate-desktop
Sorry, i don't do this work for you.

I don't see any harm in tracking this downstream too.

Okay I will report upstream against the version in Fedora 20.

Done: https://github.com/mate-desktop/mate-panel/issues/163