Opened 13 months ago

Last modified 3 months ago

#14711 new bug

[kernel] crashes by running Settlers game in DOSBox

Reported by: diver Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version: R1/Development
Keywords: Cc: ttcoder, mmlr
Blocked By: #14714 Blocking: #14017
Has a Patch: no Platform: x86

Description (last modified by diver)

hrev52547, 32bit Haiku

To reproduce:

pkgmain ins dosbox
DOSBox
mount c /boot/home
c:
sett.exe

Attachments (2)

kdl.jpg (133.1 KB ) - added by diver 13 months ago.
SETT.EXE (652.4 KB ) - added by diver 13 months ago.

Download all attachments as: .zip

Change History (12)

by diver, 13 months ago

Attachment: kdl.jpg added

comment:1 by diver, 13 months ago

Description: modified (diff)

by diver, 13 months ago

Attachment: SETT.EXE added

comment:2 by diver, 13 months ago

x86_64 seems unaffected. However, DOSBox quits with this message:

Exit to error: DRC64:Unhandled memory reference

comment:3 by ttcoder, 13 months ago

Cc: ttcoder added

Same here. Curiously, the kernel crash goes away if downgrading the package: if I fetch an older version (revision, actually: something like dosbox 0.74-1 instead of 0.74-3, gotta check) from the "administrative" folder, and install that, I can play with 100% stability.

comment:4 by waddlesplash, 13 months ago

Blocked By: 14714 added

comment:5 by waddlesplash, 12 months ago

int_bottom_user for 32-bit unconditionally disables interrupts and doesn't re-enable them: http://xref.plausible.coop/source/xref/haiku/src/system/kernel/arch/x86/32/interrupts.S#553

int_bottom_user for 64-bit never disables interrupts at all: http://xref.plausible.coop/source/xref/haiku/src/system/kernel/arch/x86/64/interrupts.S#244

So, it seems 32-bit int_bottom_user should just leave interrupts enabled, yes? Or is there something else I'm missing? The interrupt handler code is largely shared between 32-bit and 64-bit, so one of these is definitely a bug.

comment:6 by waddlesplash, 12 months ago

Blocking: 14017 added

comment:7 by waddlesplash, 12 months ago

Cc: mmlr added

CC mmlr: you know more about the x86 interrupt handling routines than I do, can you check my above analysis?

comment:8 by mmlr, 12 months ago

As discussed on IRC, the panic states that interrupts were disabled at fault time, i.e. iframe flags has the interrupt flag cleared, not that they are disabled when entering the handler.

Interrupts are supposed to be disabled at/by the int_bottom_user and stay disabled into the handler functions, as the comment in the x86 version states. The pagefault handler reenables them after doing its initial checks.

The difference between x86 and x86_64 is that the latter always uses syscall/sysret instead of possibly using legacy software interrupts and the mask MSR includes the interrupt flag bit. Hence in x86_64 interrupts are always already disabled when reaching int_bottom_user and there is no need for disabling them there through cli.

comment:9 by KapiX, 10 months ago

I've seen this when I replaced an .so used by a running program. However, I did not manage to reproduce it (got it once, most of the time it just crashes). Stack trace is not really relevant, since it crashed in border_style() (called from BWindow::task_looper).

comment:10 by waddlesplash, 3 months ago

As per #14017, this occurs on x64 too. x64 uses SYSRET and IRET to return to userland; SYSRET gets RFLAGS from R11, whereas IRET gets RFLAGS from the stack. I didn't verify that the R11 vs. stack handling is correct in our interrupt code, but if it is, that would kick this bug into the iframe handling, I think?

Note: See TracTickets for help on using tickets.