[kernel] problems opening png image from ext3 partition

[diver]

I mounted my ext3 partition (nice work btw, Axel!) where I store my "/home" folder in Ubuntu.

I launched some files (mp3, txt) and they all opened just fine. Then I tried to open .png image, after that I noticed frozen ShowImage window (which couldn't be killed) and high cpu activity.

I then took a look at which thread consumed cpu power and it was syslog_sender. Then I did "tail -f /var/log/syslog" and I saw that much information is being written and continue to writing to syslog. So I typed sync just in case.

Then I tried to unmount that ext3 partition from Tracker using "Force unmount" button. After that partition didn't disappear from Desktop, but disappeared from "/" folder and Desktop context menu. I decided to reboot and shutdown window said that Tracker is not responding, I used kill button and after that reboot completed.

[diver]

.png image in question

[diver]

I just tried again and I could reproduce it. Am I right tat this could point to 3 issues? 1. Unkillable ShowImage window. 2. Refresh desktop icons after force unmount 3. Something is wrong with this .png image.

[korli]

Seems it's due to Michael's changes to kernel heap allocator. Reassigning to let him check.

[mmlr]

Nope, except for the missing newline in the dprintf (fixed in r26251) there's nothing wrong from the heap perspective. With previous revisions of the heap this would simply have hit a panic("huge allocation") right away while the requests are now handled through areas. The debug output is purely informational. The real problem at hand is that someone actually allocates/reallocates such a huge amount of memory through the kernel heap. Since this is happening from an ext3 partition and the corresponding filesystem add-on is pretty new still I'll take the liberty to reassign this back to Axel :-)

[mmlr]

Looking through it only quickly I would point my finger at ext2_read_pages(). There file_map_translate() is called, which in turn adds vectors to the file map, which then reallocates the array. This is the only place I could see a realloc coming from. Note that taking an allocation size of 8298240 bytes would amount to an extent count of 345760, as each file_extent is 24 bytes. So I guess either the ext2_read_pages() function has a problem, or something got messed up so the ext2 filesystem add-on actually thinks it requires such a large amount of file_extents.

[axeld]

In fact, the file map implementation was pretty simple - it was enough for the extent based BFS, but wasn't up to handle something like ext2.

I've improved it in r26260, but we should actually use a sparse array, and don't need to have space for the whole file (right now, it allows for partial maps, but only it still has to be contiguous, and start from offset 0). Even though it should rarely happen for real, but ext2 could easily need as many extents as outlined by Michael; it remembers each file block individually. It would also be nice if we could flush the file map in low memory situations.

[diver]

Can't reproduce it anymore.

[korli]

Thanks for the update!