Panic broken on Windows XP

[arcnmx]

On Windows XP, the program fn main() { panic!() } will fail to run with the following:

thread panicked while processing panic. aborting.

I understand that XP isn't necessarily supported by the standard library, and certain sync implementations are stubbed out (probably the root cause of this issue?), but panicking seems like an operation that should really work if at all possible...

Tested with i686-pc-windows-gnu target and mingw-w64 on:

rustc 1.11.0-nightly (ad7fe6521 2016-06-23)
binary: rustc
commit-hash: ad7fe6521b8a59d84102113ad660edb21de2cba6
commit-date: 2016-06-23
host: x86_64-unknown-linux-gnu
release: 1.11.0-nightly

[alexcrichton]

Indeed this should definitely work! Would you be able to debug a bit and explore why the double panic is happening? (e.g. the panic messages that were printed or the stack traces)

[alexcrichton]

I'm also not sure I've ever heard of pc-windows-gnu working on XP, so MSVC may work better. Even then though we don't regularly test so it may still have regressed.

[arcnmx]

@alexcrichton

Hm, I can try to see if I can install a debugger and get more info, but I did find notify-rs/notify#79 (comment) which seems to include a stack trace of the same issue happening with a double panic.

I'm also not sure I've ever heard of pc-windows-gnu working on XP, so MSVC may work better

It seems to work well enough here, besides the aforementioned issue. If I don't trigger a panic most basic functionality seems fine! I don't have a MSVC Rust dev setup, but if anyone wants to compile the minimal test program and attach an exe I can try running it!

[alexcrichton]

Aha, that'd do it. When a thread panics it attempts to run its panic hook, but that panic hook is protected by an RwLock which is in turn not implemented on XP. That means that when panicking you'll panic immediately as you attempt to acquire an rwlock.

We could change this to use a mutex somehow perhaps which I believe is implemented on XP at least.

[retep998]

Alternatively all of Rust's synchronization primitives could be replaced by versions from parking_lot which works on XP (and is faster). cc @Amanieu

[steveklabnik]

Triage: no changes I'm aware of

[mbilker]

I found that this happens to me too. I may go and modify the panic handler to use a Mutex rather than an RWLock so I can find out why this program I am writing is panic-ing on Windows XP Embedded.

[mbilker]

Would there be too much of a performance hit if RWLock checks for SRW lock support at runtime like Mutex? Could always implement it and do a crater run to find out myself.

Mutexes work on XP since it falls back to using CriticalSection* functions.

[jonas-schievink]

Triage: #56410 will switch libstd to use parking_lot, but it's still got a long way to go

[mbilker]

I've been using the changes from #56410 in a small program running on Windows XP Embedded machines for a few months now with working panic messages.

[arcnmx]

(I love that most of the interest in XP and the reason this issue was filed seems to stem from one certain company's use of XP Embedded in their arcade cabinets)

[RalfJung]

Would there be too much of a performance hit if RWLock checks for SRW lock support at runtime like Mutex? Could always implement it and do a crater run to find out myself.

An alternative would be to make RwLock fall back to EnterCriticalSection similar to what Mutex already does. Yes that would mean it's not an actual reader-writer lock (there'd be no concurrent readers, though many readers from the same thread would still work), but that still seems better than panicking...

[mbilker]

An alternative would be to make RwLock fall back to EnterCriticalSection similar to what Mutex already does. Yes that would mean it's not an actual reader-writer lock (there'd be no concurrent readers, though many readers from the same thread would still work), but that still seems better than panicking...

In a previous issue regarding Windows XP fallback implementations, MrAlert did this a little bit lower-level so it is definitely possible [1].

[1] #26654 (comment)

[mbilker]

Though, after looking at that implementation again, I would not use it because the keyed events APIs are undocumented.

[mbilker]

@RalfJung I decided to follow your advise and threw together a PoC using a wrapper around ReentrantMutex as a fallback when SRW functions are not available using a similar method to what the Windows' Mutex implementation is doing.

https://github.com/mbilker/rust/tree/srwlock-compat-mutex
mbilker@9d5febc

[RalfJung]

@mbilker nice, that is somewhat like what I had in mind. :)

I imagine the underlying "reentrant mutex" can be shared with the Mutex implementation, to avoid duplicating all that kind logic? Basically, a Windows Mutex could just be a wrapper around RwLock that only exposes write locks. (That is effectively how they are already implemented on Windows Vista+: they use AcquireSRWLockExclusive.)

[mbilker]

@RalfJung It is using the ReentrantMutex code from Mutex.

rust/src/libstd/sys/windows/mutex.rs

Lines 152 to 184 in 57e1da5

	pub struct ReentrantMutex {
	inner: UnsafeCell<MaybeUninit<c::CRITICAL_SECTION>>,
	}
	unsafe impl Send for ReentrantMutex {}
	unsafe impl Sync for ReentrantMutex {}
	impl ReentrantMutex {
	pub fn uninitialized() -> ReentrantMutex {
	ReentrantMutex { inner: UnsafeCell::new(MaybeUninit::uninit()) }
	}
	pub unsafe fn init(&mut self) {
	c::InitializeCriticalSection((&mut *self.inner.get()).as_mut_ptr());
	}
	pub unsafe fn lock(&self) {
	c::EnterCriticalSection((&mut *self.inner.get()).as_mut_ptr());
	}
	#[inline]
	pub unsafe fn try_lock(&self) -> bool {
	c::TryEnterCriticalSection((&mut *self.inner.get()).as_mut_ptr()) != 0
	}
	pub unsafe fn unlock(&self) {
	c::LeaveCriticalSection((&mut *self.inner.get()).as_mut_ptr());
	}
	pub unsafe fn destroy(&self) {
	c::DeleteCriticalSection((&mut *self.inner.get()).as_mut_ptr());
	}
	}

[RalfJung]

What I meant is that all of this code is now essentially duplicated:

rust/src/libstd/sys/windows/mutex.rs

Lines 48 to 150 in 57e1da5

	impl Mutex {
	pub const fn new() -> Mutex {
	Mutex {
	// This works because SRWLOCK_INIT is 0 (wrapped in a struct), so we are also properly
	// initializing an SRWLOCK here.
	lock: AtomicUsize::new(0),
	held: UnsafeCell::new(false),
	}
	}
	#[inline]
	pub unsafe fn init(&mut self) {}
	pub unsafe fn lock(&self) {
	match kind() {
	Kind::SRWLock => c::AcquireSRWLockExclusive(raw(self)),
	Kind::CriticalSection => {
	let re = self.remutex();
	(*re).lock();
	if !self.flag_locked() {
	(*re).unlock();
	panic!("cannot recursively lock a mutex");
	}
	}
	}
	}
	pub unsafe fn try_lock(&self) -> bool {
	match kind() {
	Kind::SRWLock => c::TryAcquireSRWLockExclusive(raw(self)) != 0,
	Kind::CriticalSection => {
	let re = self.remutex();
	if !(*re).try_lock() {
	false
	} else if self.flag_locked() {
	true
	} else {
	(*re).unlock();
	false
	}
	}
	}
	}
	pub unsafe fn unlock(&self) {
	*self.held.get() = false;
	match kind() {
	Kind::SRWLock => c::ReleaseSRWLockExclusive(raw(self)),
	Kind::CriticalSection => (*self.remutex()).unlock(),
	}
	}
	pub unsafe fn destroy(&self) {
	match kind() {
	Kind::SRWLock => {}
	Kind::CriticalSection => match self.lock.load(Ordering::SeqCst) {
	0 => {}
	n => {
	Box::from_raw(n as *mut ReentrantMutex).destroy();
	}
	},
	}
	}
	unsafe fn remutex(&self) -> *mut ReentrantMutex {
	match self.lock.load(Ordering::SeqCst) {
	0 => {}
	n => return n as *mut _,
	}
	let mut re = box ReentrantMutex::uninitialized();
	re.init();
	let re = Box::into_raw(re);
	match self.lock.compare_and_swap(0, re as usize, Ordering::SeqCst) {
	0 => re,
	n => {
	Box::from_raw(re).destroy();
	n as *mut _
	}
	}
	}
	unsafe fn flag_locked(&self) -> bool {
	if *self.held.get() {
	false
	} else {
	*self.held.get() = true;
	true
	}
	}
	}
	fn kind() -> Kind {
	static KIND: AtomicUsize = AtomicUsize::new(0);
	let val = KIND.load(Ordering::SeqCst);
	if val == Kind::SRWLock as usize {
	return Kind::SRWLock;
	} else if val == Kind::CriticalSection as usize {
	return Kind::CriticalSection;
	}
	let ret = match compat::lookup("kernel32", "AcquireSRWLockExclusive") {
	None => Kind::CriticalSection,
	Some(..) => Kind::SRWLock,
	};
	KIND.store(ret as usize, Ordering::SeqCst);
	ret
	}

[mbilker]

Ah yeah true. I now have Mutex using RWLock but will need to run the test suite to ensure this works alright. I also discovered the Windows Condvar implementation uses SleepConditionVariableSRW so that will need to be corrected to use SleepConditionVariableCS when RWLock is backed by critical sections.

[mbilker]

Sorry for the delay. Are there any testing project out there for testing the Rust synchronization APIs?

[RalfJung]

Well as a start there is the RwLock test suite. Mutex also has one.

[mbilker]

So testing my changes would be with python x.py test src/libstd/sync?

EDIT: It was python x.py test src/libstd. Looks like all the tests pass.

[RalfJung]

On Linux I'd do ./x.py test --stage 0 --no-doc src/libstd. The --stage 0 avoids building the entire compiler, twice, just to run some libstd tests.

[mbilker]

Considering the nature of this issue, if a panic occurs and the dbghelp.dll is the stock DLL included with Windows XP, then SymInitializeW is not available, only SymInitialize, causing a double panic.

[mbilker]

This was after some testing, if I copied a slightly newer dbghelp.dll over into the DLL search path (in my case, the same directory as the executable), then no issues whatsoever. I do need some way to handle recursive locking or follow the old behavior and use a writer count of some sort since that's how EnterCriticalSection works.

[mbilker]

There's also some other functions that are not available so I am in the middle of putting in the necessary changes into backtrace-rs so it doesn't attempt to unwrap on missing symbols.

[jeroen]

Hi all,

I would like to build a binary for librsvg that can run on Windows 2008 (Vista). I am going to try to build a custom version of rust just to accomplish this.

Currently on Vista/2008 we get the rust dll error that about missing SetThreadErrorMode in the system api. Would a patch like this solve the issue? https://github.com/jeroen/rust/pull/1

[RalfJung]

@jeroen This bug here is about Windows XP specifically, because it lacks SRW (slim reader writer) locks. Vista+ have SRW locks so your problem is likely unrelated. Please open a new issue.

[wesleywiser]

Closing as Windows XP is no longer supported rust-lang/compiler-team#378