Opened 8 years ago

Closed 8 years ago

#7998 closed bug (fixed)

Unhandled Page Fault When Compiling Haiku Source On Nightly r42768

Reported by: Don Quixote Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: unhandled page fault, jam, build Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

I installed the nightly hrev42768 VMDK under VirtualBox. I mounted the blank disk image that was provided in the tarball as writable, then did an anonymous SVN checkout of the Haiku source tree.

I set up a separate directory to hold the object files:

 $ mkdir i686
 $ cd i686
 $ ../Source/haiku/haiku/configure
 $ jam -q @alpha-raw

The build ran from a few minutes then entered kernel debugging land with the attached crash dump. It's a screen shot - is there a way to save it to a text file, or to the clipboard from VirtualBox?

It's still in kernel debugging land with the keyboard working if you want me to do something to debug it.

Attachments (2)

Screenshot-Haiku r42768 [Running] - VirtualBox OSE-1.png (44.4 KB ) - added by Don Quixote 8 years ago.
unhandled page fault when building Haiku in nightly hrev42768
Haiku r42768.vbox (6.4 KB ) - added by Don Quixote 8 years ago.
XML file with the VirtualBox config for my Haiku Nightly hrev42768 VM.

Download all attachments as: .zip

Change History (9)

by Don Quixote, 8 years ago

unhandled page fault when building Haiku in nightly hrev42768

comment:1 by Don Quixote, 8 years ago

The VirtualBox VM is configured with 1024 MB of memory, with Virtual Memory enabled within Haiku. I/O APIC and VT-x are enabled - should they be?

by Don Quixote, 8 years ago

Attachment: Haiku r42768.vbox added

XML file with the VirtualBox config for my Haiku Nightly hrev42768 VM.

comment:2 by Don Quixote, 8 years ago

My host is an early 2006 MacBook Pro (Core Duo, NOT Core 2 Duo, model identifier MacBookPro1,1) running Ubuntu 11.04. It has 2 GB of physical memory, with no virtual memory.

comment:3 by bonefish, 8 years ago

Owner: changed from axeld to bonefish
Status: newassigned

I'd assume fork_team() failed (probably due to lack of memory) before the new thread object could be added to the new team, hence, when the thread destructor is called, its team is still NULL and Thread::DeleteUserTimers() invokes UserDefinedTimersRemoved() on a NULL team object.

The solution would be in Thread::DeleteUserTimers() to only invoke UserDefinedTimersRemoved() when count is greater than 0.

I don't know when I'll get to apply that change, so if anyone wants to beat me to it, feel free.

comment:4 by Don Quixote, 8 years ago

Are we forking a multithreaded process? BeOS could not do that, one could fork only when the only thread was the one that entered main(). Does Haiku support multithreaded forks?

in reply to:  4 comment:5 by bonefish, 8 years ago

Replying to Don Quixote:

Are we forking a multithreaded process?

In this case, no, jam is single-threaded.

BeOS could not do that, one could fork only when the only thread was the one that entered main(). Does Haiku support multithreaded forks?

Haiku supports fork() being called in any thread.

in reply to:  3 comment:6 by anevilyak, 8 years ago

Replying to bonefish:

The solution would be in Thread::DeleteUserTimers() to only invoke UserDefinedTimersRemoved() when count is greater than 0.

Done in hrev42776.

comment:7 by bonefish, 8 years ago

Resolution: fixed
Status: assignedclosed

Thanks a lot! Closing as fixed. Please reopen, if you encounter it again.

Note: See TracTickets for help on using tickets.