Bug 92235 - Going from having multiple search playlists open to only one causes JuK to eat up all available RAM
Summary: Going from having multiple search playlists open to only one causes JuK to ea...
Status: RESOLVED DUPLICATE of bug 91467
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: 2.1.1
Platform: Slackware Linux
: NOR crash
Target Milestone: ---
Assignee: Scott Wheeler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-28 03:14 UTC by Benjamin M.
Modified: 2004-10-30 00:13 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin M. 2004-10-28 03:14:18 UTC
Version:           2.1.1 (using KDE KDE 3.3.1)
Installed from:    Slackware Packages
Compiler:          gcc 3.3.4 
OS:                Linux

While a song is playing and I have multiple search playlists open, if I double click on one of the selected search playlists JuK will hang and will use up all available RAM (and swap) until the kernel kills JuK.

Steps to reproduce:
1) Select multiple search playlists (using 3 consistently causes the bug, I don't know about any other numbers)
2) Begin playing a song (hit play button)
3) Double click on one of the selected playlists (double clicking on one of the search playlists that are not already selected doesn't seem to cause this problem)
4) Sit and watch JuK eat up RAM

Here are the kernel messages from /var/log/syslog (I am using kernel-2.6.9-mm1, with a couple of other patches):
Oct 27 21:07:36 zero kernel: oom-killer: gfp_mask=0x1d2
Oct 27 21:07:39 zero kernel: DMA per-cpu:
Oct 27 21:07:39 zero kernel: cpu 0 hot: low 2, high 6, batch 1
Oct 27 21:07:39 zero kernel: cpu 0 cold: low 0, high 2, batch 1
Oct 27 21:07:39 zero kernel: Normal per-cpu:
Oct 27 21:07:39 zero kernel: cpu 0 hot: low 28, high 84, batch 14
Oct 27 21:07:39 zero kernel: cpu 0 cold: low 0, high 28, batch 14
Oct 27 21:07:39 zero kernel: HighMem per-cpu: empty
Oct 27 21:07:39 zero kernel: 
Oct 27 21:07:39 zero kernel: Free pages:         732kB (0kB HighMem)
Oct 27 21:07:39 zero kernel: Active:29970 inactive:29678 dirty:0 writeback:0 unstable:0 free:183 slab:2213 mapped:58209 pagetables:449
Oct 27 21:07:39 zero kernel: DMA free:52kB min:28kB low:56kB high:84kB active:6160kB inactive:5636kB present:16384kB pages_scanned:7968 all_unreclaimable? no
Oct 27 21:07:39 zero kernel: protections[]: 0 0 0
Oct 27 21:07:40 zero kernel: Normal free:680kB min:476kB low:952kB high:1428kB active:113720kB inactive:113076kB present:245696kB pages_scanned:87168 all_unreclaimable? no
Oct 27 21:07:40 zero kernel: protections[]: 0 0 0
Oct 27 21:07:40 zero kernel: HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Oct 27 21:07:40 zero kernel: protections[]: 0 0 0
Oct 27 21:07:40 zero kernel: DMA: 7*4kB 1*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 52kB
Oct 27 21:07:40 zero kernel: Normal: 34*4kB 8*8kB 2*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 680kB
Oct 27 21:07:40 zero kernel: HighMem: empty
Oct 27 21:07:40 zero kernel: Swap cache: add 653779, delete 653755, find 9733/14660, race 0+2
Oct 27 21:07:40 zero kernel: Out of Memory: Killed process 4066 (juk).
Comment 1 Scott Wheeler 2004-10-28 04:23:19 UTC
My guess is that this is yet another duplicate of 91467.  Do you also see this at the end of playlists?
Comment 2 Benjamin M. 2004-10-29 23:13:18 UTC
Yep - I do see the same thing at the end of playlists.  However, I can trigger this even with "Loop Playlist" enabled.  I don't know how JuK is designed, so I'll leave it up to you to decide wheather this is caused by the same bug.
Comment 3 Scott Wheeler 2004-10-30 00:13:31 UTC
Yeah, this was something that has caused a lot of weird crashes; fortunately it was only in CVS for a few days.  Unfortunately the 3.3.1 release happened during those few days.

*** This bug has been marked as a duplicate of 91467 ***