Something is secretly eating up my Acer Iconia A500 internal memory and I need help finding it I've been a happy owner of an Acer Iconia A500 for a bit over a year now but a couple of weeks ago it started to complain about its internal memory being full. 
I was a bit surprised as I keep movies, and such on the external SD card but I assumed is was some browser cache, Maps or so which had eaten up a fair chunk of the 32G memory it has internally. 

However, that doesn't seem to be the case. I have cleared the data of almost every single App I have installed but still if I look at the Storage tab of the settings I see the following (a couple of hours ago):



I get the feeling that the rightmost grey part of the bar should be a bit more than 379MB(the Available part)... (SD Card at the bottom of the picture is the external one, never mind that one).

I've tried almost every disk usage app available out there and they all show similar results, the following is DiskView (picture taken after I removed a few apps):



(in this picture "SD Card" is the internal one...)

One thing all the disk usage apps seems to have in common is that unless the device is rooted, they cannot see what is in some directories (like /data) which makes me think it is either Android itself (4.0.3 on this device) which has some kind of cache which is misbehaving or that some process is producing extreme amounts of logs somewhere.

Sorry for this long intro, but the basic question is: How do I proceed? 

I guess one alternative is to find what is worth backing up and do a factory reset or something but I wold really like to find out what happened first.

Rooting it is an alternative which would probably help me find out more but I sort of like it as it is (except for this issue). If it is needed to resolve it I could of course do it but it feels like you shouldn't have to with an appliance like this.

Is there another way forward? I have this naive hope that there is a button somewhere I haven't seen that clears all logs or reduce the log level from debug to info.

Edit: One thing I've been considering but cannot investigate is if it could be cores. I've had a lot of crashes lately (presumably because it has been running low on disk).
In response to Izzy's comment below. Apps adds up to more or less exactly the 700MB listed as "Apps" (seems to be the total of data and the apps themselves).
Here are some key points to this problem. Though not all of them applied in this case, I will still include all of them -- as in another case they might prove helpful:


A good starting point to check is apps -> manage apps in Androids system menu, which lists all apps+data and can be sorted by size, to identify the "biggest consumers". While here, you can "delete" too-big caches (per app)
some directories in the file system cannot be investigated without having root privileges, so the preferred du -k|sort -n (to find the biggest files) would e.g. skip directories below /data
still, having a terminal emulator available (Android Terminal Emulator would be a good candidate), at least a df -h could show where free space goes toward zero (see screenshot below). In case the -h parameter ("human readable") is not understood on your system, you might try to replace it by -m ("megabytes"), -k ("kilobytes"), or omit it completely.
The article Debugging Android core dumps describes "core dumps" under Android are called "Tombstones", and stored globally as /data/tombstones/tombstone_nn, with "nn" simply being a counter. As many crashes were reported, this might be a place "filling up" (see below). But only 2.5MB could be located here in this case.
According to Android Forensics by Andrew Hoog, it might be worth diving into /data/local: The “/data/local” directory is important as it allows shell (the user account nonrooted phones run adbd as) read/write access. When an app is installed, it is first copied to “/data/local.” Which means, even on non-rooted devices one should be able to dig in here.
SD Maid - System cleaning tool might find some more orphans -- but without root access, this apps capabilities are limited.
If the "big egg" cannot be found and removed, one can either start to uninstall some apps, cleaning "big data" from others (see first step), or, as a last resort, there always remains the factory-reset which should clean up everything -- but be aware: all your downloaded apps and all your data (on internal storage only, of course -- SD card will not be affected) will get removed as well when you do this.
if still unable to solve the issue, a last resort is a factory reset. But before doing that it would be good to be prepared for the next time, so one last chance are a few steps immediately before the factory reset:


backup as much data/apps as you need and can
switch to airplane mode -- the market must not know what we are doing now
one by one, uninstall your apps (for system apps which cannot be uninstalled: uninstall their updates, clear cache and data). After each uninstall, check your free space for unexpected "big jumps". If such a "jump" happens: Note the app uninstalled at this place -- it has to be a/the evil one. Continue if it still doesn't make up for the missing space
when finished with the last one, go to the "point of no return", pull the plug, do the factory reset. It's over now ;(
after the reboot, re-configure your "virgin device" with your original market account data (you remember them hopefully?). As we made sure the market stood uninformed of our actions from step 2 on, you should now be able to re-sync your apps and some data. The apps for sure, the data only provided you synced them with the market before step 2.
keep an eye on the "evil app(s)", if you detected any at step 3. You may want to remove these (now or later).



The following screenshot shows the output of df -h on a Motorola Droid 2. As you can see, there are 2 mount points on internal storage which could be candidates for "getting filled": /data (the most likely -- and got the hit in this case) plus /cache. The command was executed without root privileges:



Tombstones: The folder's location is /data/tombstones. Permissions of the /data directory are drwxrwxr-x, the tombstones subdirectory has drwxr-xr-x -- so they are accessible also on non-rooted devices. Using a terminal emulator (see above), you can cd /data/tombstones and do a ls -l to see whether there are any tombstones, and what size they occupy. Unfortunately, all tombstones are owned by system, and permissions are set to rwx------ -- so if that's your troublemaker: you cannot remove them without root :( Have a good backup (huh? how, without root?), and probably a factory-reset will be your last resort...