compcache 0.4 crashes on ARM

[GoogleCodeExporter]

What steps will reproduce the problem?
1. use compcache by swapon /dev/compcache0 -p 1or swapon /dev/compcache -p 1
2.
3.

What is the expected output? What do you see instead?
frozen screen

What version of the product are you using? On what operating system?
latest. ubuntu 7.10 , 8.04 alpha 5, debian-eabi 2.6.24, 2.6.23, 2.6.21

Please provide any additional information below.
 this project is not stable, it will lock up any linux machine, SMP or not,
embedded or desktop.

Original issue reported on code.google.com by marblema...@gmail.com on 3 Mar 2008 at 8:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am thinking that the new unstable packages in debian-unstable may be to blame

Original comment by marblema...@gmail.com on 11 Mar 2008 at 8:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It really just takes hours and hours and hours for this to happen. Just leaving 
the
system idle long enough does it for me while using compcache-0.2 with X and the
Ubuntu 8.04 alpha-6 branch -- this is exactly what happened to me : 

Left the machine on with compcache using 2gb's of DDR, set default setting for 
512MB
Compressed Cache 

i went to go sleep because it was 5am! lol

Woke up and tried to immediately switch from icewm-session workspace 1 to 
workspace 2
by holding Ctrl+Alt + Left

the second i tried to do that, the top program i was running just stopped,,
everything stopped. I tried pressing Ctrl+Alt+Backspace to restart the X 
session...
it was able to stop X, but it just hanged there for as long as me to go out to 
the
doctors office and get back......

So i did a Hard Reboot.

unfortunately the /proc/tlsf and /proc/compcache were no longer available after 
that
reboot.

I also noticed that when TOP was frozen, alot of programs were hogging up CPU 
usage
such as NetworkManager etc i wish i could of taken a screenshot but it was just 
not
even possable to move the mouse!

I think that if you follow those steps, and keep top running, you'll have this
reproduced in less than a day

Original comment by marblema...@gmail.com on 11 Mar 2008 at 8:50

[GoogleCodeExporter]

could i startx with strace??

strace startx -o compcache_strace_debug_x.txt

Original comment by marblema...@gmail.com on 11 Mar 2008 at 8:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I cant confirm yet that this bug effects debian-lenny debian-sarge or 
debian-etch. I
can only confirm it definitely effects debian-sid (unstable) , not 
testing-lenny.
Which really makes me believe its some unstable package causing the bug.

I get alot of 
"XIO" errors in the terminal when X crashes

Original comment by marblema...@gmail.com on 11 Mar 2008 at 9:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I ran  strace aptitude update -o compcache_strace_debug_aptitude_update.txt
on my ARM computer with 64MB SDRAM, aptitude failed with ./use_compcache (15mb
compcache default 25%) but there was no file named
compcache_strace_debug_aptitude_update.txt
in that directory i was working in (my /root work directory)
is the file placed elsewhere? 

Original comment by marblema...@gmail.com on 12 Mar 2008 at 1:41

[GoogleCodeExporter]

> I ran  strace aptitude update -o compcache_strace_debug_aptitude_update.txt
> on my ARM computer with 64MB SDRAM, aptitude failed with ./use_compcache (15mb
> compcache default 25%) but there was no file named
> compcache_strace_debug_aptitude_update.txt

My bad. Try: strace -o debug_apt.txt aptitude update
(-o arg must come first)

Original comment by nitingupta910@gmail.com on 12 Mar 2008 at 7:45

[GoogleCodeExporter]

> I cant confirm yet that this bug effects debian-lenny debian-sarge or 
debian-etch. I
> can only confirm it definitely effects debian-sid (unstable) , not 
testing-lenny.
> Which really makes me believe its some unstable package causing the bug.

Can you check if you get same problems on this debian-sid *without* compcache? 
Apply
same kind of workload and leave it idle overnight or so?

Original comment by nitingupta910@gmail.com on 12 Mar 2008 at 7:52

[GoogleCodeExporter]

Changing summary based on comment #160.

Original comment by nitingupta910@gmail.com on 12 Mar 2008 at 7:57

• Changed title: debian-sid(unstable) freezes with compcache-0.2 after leaving system idle for long time

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

i can confirm the problem only exists when using compcache, my system is 
increadably
stable (even though the dist is named unstable, its quite stable)

Original comment by marblema...@gmail.com on 13 Mar 2008 at 12:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

so aside from using compcache, debian-unstable is the most stable operating 
system
ive used with the most up-to-date packages, great bleeding edge system with very
amazing stability... untill i use compcache-0.2 svn... 

Original comment by marblema...@gmail.com on 13 Mar 2008 at 12:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I use the system constantly, always all the time its running, when i use 
compcache it
dies after i use it for a while. depends on how much compcache space im using, 
if im
using the default and not running x then the crash only effects ssh, apt-get, 
dpkg,
aptitude, etc etc etc,...

i dont know what else to say other than you'll have no problems reproducing 
this bug
using the latest compcache svn checkout, running an installed on hard drive 
version 
naitve without the use of windows xp or vmware (in other words installed on 
your hard
drive and booted up with grub or lilo) of Ubuntu 32-bit DVD of Alpha-6, fully
apt-get updated,upgraded,dist-upgrade , apt-get -f install then just compile 
build
and run compcache and wait long enough in a running x session and things will 
get
buggy after a day of constant use , maybe more depends on your resources i 
believe. i
always keep top running in an open xterm to see whats going on.

thanks for being patient.

Original comment by marblema...@gmail.com on 13 Mar 2008 at 1:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just havent ever seen X crash before no matter how much load i put on my 
systems, I
can tell you that I cannot reproduce the bug without the use of compcache. I 
can also
say I always have my systems on, and running a crap load of programs, compile a
kernel or 2, running top, compile lorcon, compile compile compile, apt-get 
update,
apt-get upgrade constantly and apt-get dist-upgrade, aptitude,
icewm-session-experimental, firefox, iceweasel, icehamster, mplayer, i really 
just
use my system to the max always. When I use compcache without X it is not so 
bad.

I do all of this on a PXA270 Arm processor manufactured by marvell with 64mb's 
of
SDRAM and a ton of swap files.
so far it has never frozen or crashed x ever without using compcache.

Original comment by marblema...@gmail.com on 13 Mar 2008 at 1:04

[GoogleCodeExporter]

the system is not freezing, its just hanging for a very long time, sometimes it 
seems
like its going to last forever, so i just reboot. I have tried waiting hours and
hours and hours for it to pass. Sometimes it does just take a very long time 
because
the system slows down to a near halt. Im working on making an strace debug of 
startx.

Original comment by marblema...@gmail.com on 13 Mar 2008 at 6:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Im now testing on Ubuntu 7.10 Stable X86 DVD installed on hard drive and booted
normally without any microsoft os or VMware involved, the Ubuntu distro is fully
update and dist-upgraded. Running latest kernel using integrated nvidia video
display. This is a very good and stable testing platform. Im using the latest
compcache overnight to see what will happen. If i do a recovery mode and then 
use
strace to startx, would that be OK?

Original comment by marblema...@gmail.com on 13 Mar 2008 at 9:02

[GoogleCodeExporter]

It seems that I have also repro'ed this same issue on Fedora8 (kernel 
2.6.24.3-12). I
now also have the backtrace and debugging the issue. Whenever I come up with 
fix, I
will let you know.

Thanks

Original comment by nitingupta910@gmail.com on 13 Mar 2008 at 10:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sweeeetness! YAY I cannot wait! I knew i was not crazy... lol I thought i would 
be
the only one there for a moment.. but yeah it just takes a very long time ... 
ive
been waitin over 12 hours on my stable ubuntu kernel 2.6.22, nothing has 
happened. So
i turned it off before something does, for now, until you debug it. ill keep 
checking
out the latest svn , ive been interested in the project since before it was on 
google
code, i was watching it for a while now its great the performance i get with my
embedded device, cant wait till its stable. Its having your ram upgraded by 
software
alone people!! priceless! comon!! its well worth the wait, im just glad i could 
help

issue should probably be renamed

Original comment by marblema...@gmail.com on 13 Mar 2008 at 9:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

do you think the bug effects kernel 2.6.22, 2.6.23, 2.6.21, etc? or just 2.6.24 
&
above? Anything i can do to aid in the debugging of compcache? thanks again.

Original comment by marblema...@gmail.com on 13 Mar 2008 at 10:52

[GoogleCodeExporter]

Linux kernel 2.6.24 using debian-eabi 65mb SDRAM:  apt-get upgrade ; fuse-utils 
glibc
compcache-0.2 subversion 55 crashed, strace output attached

Original comment by marblema...@gmail.com on 14 Mar 2008 at 10:33

Attachments:

• apt-get-compcache-0.2-svn-55-debug.out

[GoogleCodeExporter]

aptitude compcache svn version 55 crash debug strace output

Original comment by marblema...@gmail.com on 15 Mar 2008 at 1:21

Attachments:

• aptitude_debug-compcache-0.2-svn-55-latest.out

[GoogleCodeExporter]

> Linux kernel 2.6.24 using debian-eabi 65mb SDRAM:  apt-get upgrade ; 
fuse-utils glibc
> compcache-0.2 subversion 55 crashed, strace output attached

Can you please send /var/log/{messages,kernel.log} from system where it crashed.
Also, please compress files when attaching - quota limit per project is 100MB 
only.

Again, do you get crash after running for long time? Did system freeze when it 
crashes?

Now, I also downloaded this Kubuntu Hardy to repro this again with rev 55.

Original comment by nitingupta910@gmail.com on 15 Mar 2008 at 11:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

never freezes up , just crashes x, aptitude, apt-get , dpkg , its strange with
different memory settings i can get aptitude to work. im just upgrading my 
embedded
memory Ball Grid Array embedded computer (zaurus SL-C1000) to 128mb
(pocketpctechs.com took care of it for only 100 bucks) in the meantime, when
compcache works ill have even more compressed ram to work with. Please email me 
when
this project is stable, thanks again. love compressed ram!!

Original comment by marblema...@gmail.com on 15 Mar 2008 at 10:17

[GoogleCodeExporter]

With rev 55, I've been running Fedora8 (fully upgraded, 256M ram) with KDE, 
kernel
compiles, periodic yum upgrades, firefox etc... for 2 days now without any 
issues.
Can you now once test compcache on any other stable release of Ubuntu? You are 
still
hitting this bug with almost 100% frequency which is really strange!

One possible explanation for this bug can be:
With just 64M of total RAM and compcache pinning lot of pages, these apps (X, 
apt*)
might be failing to allocate memory which exposes some bugs in these apps. When 
you
increase memory chances of these failed allocs decrease substantially which 
keeps
these apps bugs under the carpet.

Original comment by nitingupta910@gmail.com on 16 Mar 2008 at 5:31

• Changed title: X and apt crashes on debian with compcache 0.2

[GoogleCodeExporter]

Id keep testing it.

Original comment by marblema...@gmail.com on 16 Mar 2008 at 6:01

[GoogleCodeExporter]

Ill see if the 64mb's is the problem in about a week, when i will have the unit
mailed back to me with 128mb's.

Original comment by marblema...@gmail.com on 16 Mar 2008 at 6:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

>With rev 55, I've been running Fedora8 (fully upgraded, 256M ram) with KDE, 
kernel
>compiles, periodic yum upgrades, firefox etc... for 2 days now without any 
issues.
>Can you now once test compcache on any other stable release of Ubuntu? You are 
still
>hitting this bug with almost 100% frequency which is really strange!

Are you using vmware or are you booting the linux os off the hard drive using 
grub/lilo?

I would keep it running without vmware for a few more days to see if its stable.

Original comment by marblema...@gmail.com on 16 Mar 2008 at 6:12

[GoogleCodeExporter]

>One possible explanation for this bug can be:
>With just 64M of total RAM and compcache pinning lot of pages, these apps (X, 
apt*)
>might be failing to allocate memory which exposes some bugs in these apps. 
When you
>increase memory chances of these failed allocs decrease substantially which 
keeps
>these apps bugs under the carpet.

I was thinking the reverse, that apt may be exposing some bugs in compcache, 
since
apt-get never has failed me before, when i use compcache however it often 
occurs.

Original comment by marblema...@gmail.com on 16 Mar 2008 at 12:01

[GoogleCodeExporter]

just incase you are right though i will try ubuntu release 7.10 with compcache
subversion latest 59 revision, or later

Original comment by marblema...@gmail.com on 16 Mar 2008 at 12:02

[GoogleCodeExporter]

Please try compcache-0.3 with 128M RAM

Original comment by nitingupta910@gmail.com on 16 Mar 2008 at 8:33