Opened 10 years ago

Closed 9 months ago

#4551 closed bug (fixed)

Hard reset when unzipping large file

Reported by: moochris Owned by: nobody
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

I copied a zipped qemu image from a FAT32 partition to a BFS partition, then tried unzipping. After around 6 seconds the machine rebooted, no KDL. After trying this a few times I actually lost that BFS partition. Tried it from my other BFS partition (boot) also, with the same reset (not lost it yet though!).

The file is 2.3 GB in size and I watched the cache memory go up to about 1600MB at the point where it reset.

syslog is attached and my specs are as follows (running on the metal btw if that's not apparent):

Asus P5KPL-CM motherboard Intel Core 2 Duo E8400 @ 3GHz 4GB ram SATA HD - 2 partitions 25GB BFS boot, 210GB BFS spare (now gone). ATI 4770HD (running in VESA)

Attachments (2)

syslog (357.7 KB) - added by moochris 10 years ago.
syslog
syslog.2 (311.9 KB) - added by moochris 10 years ago.
New syslog from SVN 33158 - no reboot (but no completion)

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by moochris

Attachment: syslog added

syslog

comment:1 Changed 10 years ago by mmlr

If you have the possibility to run a trunk build of Haiku I'd be interested if you're able to reproduce it there as well. This might be caused by an address-space overflow which was fixed in trunk in the meantime.

comment:2 in reply to:  1 ; Changed 10 years ago by moochris

Replying to mmlr:

If you have the possibility to run a trunk build of Haiku I'd be interested if you're able to reproduce it there as well. This might be caused by an address-space overflow which was fixed in trunk in the meantime.

I haven't been able to build from SVN since I switched from 32bit to 64bit Linux as the build environment. I can try a nightly though, as soon as they are available again.

comment:3 in reply to:  2 ; Changed 10 years ago by mmadia

Replying to moochris:

I haven't been able to build from SVN since I switched from 32bit to 64bit Linux as the build environment. I can try a nightly though, as soon as they are available again.

http://www.haiku-os.org/guides http://www.haiku-os.org/guides/building/pre-reqs http://www.haiku-os.org/guides/building/configure/use-32bit

Those links should help. Though not all 64bit distros are capable, eg FreeBSD 64.

comment:4 in reply to:  3 Changed 10 years ago by moochris

Replying to mmadia:

Those links should help. Though not all 64bit distros are capable, eg FreeBSD 64.

Hi, thanks - I did actually build OK this morning before setting off for work, so not had a chance to test yet. I remember that the reason I stopped building when switching to 64bit was due to being GCC4 only which, not sure about hybrid? Anyway, I'll try it out when I get home later.

Changed 10 years ago by moochris

Attachment: syslog.2 added

New syslog from SVN 33158 - no reboot (but no completion)

comment:5 Changed 10 years ago by moochris

I've install 33158 from trunk and tried again. The machine didn't reboot this time, but after waiting 2 hours, I think the zip file wasn't going to be expanded at all - had to kill the process by rebooting and I've attached the new syslog.

Thanks, Chris

comment:6 Changed 10 years ago by mmlr

It certainly sounds like this kind of action could cause an address space to run full. It sounds though that the reboot cause has been fixed by the overflow fixes.

The errors from the log look a bit strange though. The thread is obviously faulting over and over, but still the thread obviously survives. It might have installed a fault handler, but even then it sounds strange that it wouldn't error out.

That the creation of a huge image file would cause the system to run into problems wouldn't be the first time though. Maybe this could be closed as the reboot issue has been fixed, with a link to the bug about the image creation issue.

comment:7 Changed 10 years ago by anevilyak

That would be #3768 presumably?

comment:8 Changed 9 years ago by Coldfirex

Still an issue with a recent build?

comment:9 Changed 9 years ago by umccullough

Sounds like original issue is resolved (see comment:5 ), Also looks like the other issue may be resolved in #3760 anyway - I propose this ticket should be closed and a new ticket opened if the freeze still occurs.

comment:10 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: newassigned

comment:11 Changed 9 months ago by waddlesplash

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.