Sounds nasty! Can't say I've experienced (or at least noticed) this, but I don't use the GPS very often.

Are you sure about the non-swappable part? It doesn't seem to lock any pages here:

Did you notice anything interesting in its smaps file?

Anyway, since DSME restarts it when killed, maybe setting an appropriate ulimit in the init script and letting the kernel look after it could work?

Well, when I noticed it was using 19 MB of resident memory measured with top (psutils) and bringing the system down to a crawl while I tryed to use Opera I just asumed it was non-swappable (because otherwise it would have swapped out) and didn't investigate more and just restarted it. Then I kept an eye on it for a few days and when confirmed it was growing again I reported it.
I'll turn it on again and have a more detailed look at it, let's see what happens.
I think the ulimit could be a good idea.

maacruz, I have noticed that GPS does that too sometimes.

So I have been following gpsdriver's memleak for a few days more and here is what I've found:
gpsdriver leaks no matter if the gps is in use or not, in fact using it didn't seem to have any effect in memory usage; smaps confirms that the leak happens in the heap as expected. It is swappable, and it will swap out causing speed issues when the leak has grown big, only to return shortly afterwards back entirely to resident memory the next time a leak happens, causing more issues by swap trashing when the tablet is in use.
The leak doesn't seem to have a clear pattern in time or size, the vmHWM/vmRSS seems to grow a few KB every few minutes while wmData remains constant, then about every hour, give or take half an hour, vmData/vmHWM/vmRSS will jump anywhere from 132 KB (usually) to a few hundred KB.
I'm going to set ulimit and see what happens.

So I did set ulimit and it didn't work at all.
Why? It seemed like dsmetool modified the ulimits, so a google search was in order to find the dsmetool source if possible. Well, I found it soon enough (http://www.freemoe.org/users/jebba/s...til/dsmetool.c) and what dsmetool does is to signal dsme, again closed source, through dbus to load the process, so the process will inherit dsme ulimits and not the rc.d script's.
The workaround, to try next, could be little ash script daemon to poll every few minutes the gpsdriver vmData size and kill it when it grows more than a given size.

Argh, yeah that'll break it :-(

Perhaps a simpler option would be to wrap a shell script around gpsdriver that just sets limits and execs it, and tell dsme to start that from the init script.

If only minigpsd could replace gpsd...
Edit: totally forgot why I was here in the first place. Is it possible to make an option for the rss rfeader to 'lock links'? Scrolling is a serious pain with links.
Or perhaps make it not refresh when in offline mode? Another annoying thing.
I like the widget on the home screen.
I know all I make is feature requests... wish I could do more

Actually, I'm using gps pretty much with a bluetooth gps mouse and navit and/or navicore and I dont see any memory leak. My uptimes are on the order of weeks and the numbers are pretty much constant.

Could it be that there is some other program interfering

We are talking here about the N810 internal gps driver

I've been fighting with gpsdriver the whole week to see how the sollution suggested by lma would work.
What I've found is that gpsdriver is terribly unstable: reboots, segfaults, erratic behaviour. All of this running in a xterm to see how the ulimit works. It doesn't, when the max vmSize is reached, it will complain with malloc failures and behave erratically instead of exiting or being killed.
So, the only sollution seems what I suggested before, a script mini daemon to kill gpsdriver when it reaches a given size. I'm actually running a similar minidaemon to notify with a led pattern when the battery is low (and turn the device in low battery profile mode, I was tired of the battery being completely drained without noticing).
Once a bit more polished, we could add that to the SSU too, providing a battery protection new feature