Opened 10 years ago

Closed 10 years ago

#4370 closed bug (fixed)

KDL in Alpha build, PANIC: page fault, but interrupt were disabled, Touching address 0xdeadbf1f

Reported by: scottmc 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

Description

This happened with the new autoconf, automake, m4 and libtool in place while trying to run configure on apr-1.3.8. Rebooted and tried again and got the same error. Screenshot attached.

Attachments (2)

100_8306b.jpg (147.9 KB) - added by scottmc 10 years ago.
100_8307b.jpg (191.4 KB) - added by scottmc 10 years ago.

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by scottmc

Attachment: 100_8306b.jpg added

Changed 10 years ago by scottmc

Attachment: 100_8307b.jpg added

comment:1 Changed 10 years ago by scottmc

Blocking: 4363 added
Component: SystemBuild System
Owner: changed from axeld to bonefish

I rolled libtool back to previous version and still got the error, so i then rolled m4 back and the error went away. So this appears to be an issue with m4-1.3.13, which is the first version since they applied some Haiku related patches upstream. Perhaps Ingo or someone else who understands the changes that were made to m4 can investigate this one. Until this one if fixed work on #4363 might get stalled.

comment:2 Changed 10 years ago by scottmc

Seems it's still there. Rolled m4 back and was trying to rebuild the new m4 and got the crash again. So maybe it's in automake or autoconf. Still troubleshooting here.

comment:3 Changed 10 years ago by umccullough

Since these are userland apps, they probably shouldn't cause KDL anyway... so chances are something is wrong with Haiku?

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

Component: Build SystemSystem/Kernel
Owner: changed from bonefish to axeld

Replying to umccullough:

Since these are userland apps, they probably shouldn't cause KDL anyway... so chances are something is wrong with Haiku?

Exactly. The thread hash table ends up with a freed thread structure entry, which is in any case a bug in the kernel.

comment:5 Changed 10 years ago by scottmc

I'm using hrev32801 installed from the image posted here: http://haiku-files.org/releases/R1Alpha1/

comment:6 Changed 10 years ago by bonefish

Might be related to #4360, which also suggests a corrupt thread structure/thread table corruption. Is this an SMP machine? If so, does the problem occur with SMP disabled in the boot menu?

comment:7 Changed 10 years ago by scottmc

This is on an AMDX2, I tried turning off SMP in the boot menu, but it then hangs on the last icon during boot. The KDL is easy to reproduce, it's happening with whatever i try to run configure on. I'll try updating my single CPU laptop and see if I can do work there for now.

comment:8 Changed 10 years ago by marcusoverhagen

Please test if this is fixed by hrev32818.

comment:9 Changed 10 years ago by scottmc

Looks like hrev32818 did indeed fix this one. Thanks.

comment:10 Changed 10 years ago by mmlr

Resolution: fixed
Status: newclosed

Fixed in hrev32818 or hrev32819 for that matter. Thanks for confirming!

Note: See TracTickets for help on using tickets.