Opened 11 years ago

Closed 11 years ago

#2483 closed bug (fixed)

[kernel] problems opening png image from ext3 partition

Reported by: diver Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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.

Attachments (2)

syslog (472.4 KB) - added by diver 11 years ago.
screen2.png (12.7 KB) - added by diver 11 years ago.
.png image in question

Download all attachments as: .zip

Change History (9)

Changed 11 years ago by diver

Attachment: syslog added

Changed 11 years ago by diver

Attachment: screen2.png added

.png image in question

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by korli

Owner: changed from axeld to mmlr

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

comment:3 Changed 11 years ago by mmlr

Owner: changed from mmlr to axeld

Nope, except for the missing newline in the dprintf (fixed in hrev26251) 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 :-)

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by 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 hrev26260, 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.

comment:6 Changed 11 years ago by diver

Can't reproduce it anymore.

comment:7 Changed 11 years ago by korli

Resolution: fixed
Status: newclosed

Thanks for the update!

Note: See TracTickets for help on using tickets.