Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pharo images can crash after sleep of OSX #72

Open
guillep opened this issue Mar 27, 2020 · 9 comments
Open

Pharo images can crash after sleep of OSX #72

guillep opened this issue Mar 27, 2020 · 9 comments

Comments

@guillep
Copy link
Member

guillep commented Mar 27, 2020

Ported from pharo-project/pharo#2422

It happens to me a lot when I launch my computer that was in sleep mode that a Pharo image crashes on OSX.

This is really annoying because I lose some code and on top of that I don't know which image it was.

Related subject: http://forum.world.st/Pharo-7-crashes-on-OSX-when-unsuspending-laptop-td5095115.html

@guillep
Copy link
Member Author

guillep commented Mar 27, 2020

We need to see if this is fixed by the headless VM

@chisandrei
Copy link
Contributor

@guillep I've been using only the headless vm for the past months and I don't remember having those crashes any more; with the non-headless vm they were happening a lot

@bencoman
Copy link
Contributor

bencoman commented Mar 27, 2020

Not completely sure its the right code, but to review other applications experiencing the same,
searching for: osx application crash after sleep "can't allocate region securely"
turned up this (refer fourth last line)...
https://opensource.apple.com/source/libmalloc/libmalloc-116.50.8/src/magazine_malloc.c.auto.html

allocate_pages_securely(szone_t *szone, size_t size, unsigned char align, int vm_page_label)
{
	mach_vm_address_t vm_addr;
	uintptr_t addr;
	mach_vm_size_t allocation_size = round_page_quanta(size);
	mach_vm_offset_t allocation_mask = ((mach_vm_offset_t)1 << align) - 1;
	int alloc_flags = VM_FLAGS_ANYWHERE | VM_MAKE_TAG(vm_page_label);
	kern_return_t kr;

	if (szone->debug_flags & DISABLE_ASLR) {
		return allocate_pages(szone, size, align, 0, vm_page_label);
	}

	if (!allocation_size) {
		allocation_size = vm_page_quanta_size;
	}
	if (allocation_size < size) { // size_t arithmetic wrapped!
		return NULL;
	}

retry:
	vm_addr = entropic_address;
	kr = mach_vm_map(mach_task_self(), &vm_addr, allocation_size, allocation_mask, 
                        alloc_flags, MEMORY_OBJECT_NULL, 0, FALSE,
			VM_PROT_DEFAULT, VM_PROT_ALL, VM_INHERIT_DEFAULT);
	if (kr == KERN_NO_SPACE) {
		vm_addr = vm_page_quanta_size;
		kr = mach_vm_map(mach_task_self(), &vm_addr, allocation_size, allocation_mask,
                              alloc_flags, MEMORY_OBJECT_NULL, 0, FALSE,
			      VM_PROT_DEFAULT, VM_PROT_ALL, VM_INHERIT_DEFAULT);
	}
	if (kr) {
		szone_error(
		      szone, 0, "can't allocate region securely", NULL, 
                      "*** mach_vm_map(size=%lu) failed (error code=%d)\n", size, kr);
		return NULL;
	}

@bencoman
Copy link
Contributor

Firefox hangs on wake up from OS X Power Nap r=spohl is interesting, since Pharo has multiple threads. Could any of them continue to run as a Power Nap app while a laptop is sleeping?
(btw, It talks about processes but IIUC OSX only has threads not processes.)

@bencoman
Copy link
Contributor

I notice this

FileMaker has accepted negative window coordinates for me in OS X for years. I just tried in 13 on Mountain Lion, I opened an 800x800 window at -1000x-1000, it was fully off screen and behaved as expected (responded to command-W).

Probably unrelated, but it does produce the same error message.

@bencoman
Copy link
Contributor

A situation that can happen when returning from fullscreen Space on shutdown is interesting.

@bencoman
Copy link
Contributor

Sorry I don't have a specific reference, but after a lot of browsing stewing in my mind, I wonder if during the laptop-sleep some graphics buffer is being discarded deep in the OS, and its not valid when Pharo references it. I wonder if the the vm should catch laptop-wakeup events (if thats possible) and hide-then-restore the Pharo window.

@bencoman
Copy link
Contributor

bencoman commented Mar 27, 2020

Summarized C backtrace....

Pharo(67603,0xa983a1c0) malloc: 
*** mach_vm_map(size=8388608) failed (error code=3)
*** error: can't allocate region securely
*** set a breakpoint in malloc_error_break to debug
Segmentation fault Tue Feb 12 17:31:59 2019
0  libobjc.A.dylib ............ GLOBAL__N_119 AutoreleasePoolPage........
1  ..........
2  ..........
3  ..........
4  ..........
5  libobjc.A.dylib .......... AutoreleasePoolPage19autoreleaseFullPage ..........
6  libobjc.A.dylib .......... objc_object16rootAutorelease2Ev
7  libobjc.A.dylib .......... objc_loadWeak 
8  AppKit .......... [NSEvent window]
9  AppKit .......... nextEventMatchingEventMask:untilDate:inMode:dequeue:
10 AppKit .......... nextEventMatchingMask:untilDate:inMode:dequeue:
11 Pharo  .......... pumpRunLoopEventSendAndSignal:

@seandenigris
Copy link

Just happened to me.

Describe the bug
When I woke my MBP 2018 up from sleep, Launcher had crashed (VM). This seems to be intermittent because I've woken my Mac up from sleep many times but this never happened before.

To Reproduce

  1. Put Mac to sleep
  2. Wake it up

Version information:

  • OS: 10.14.6
  • Version: Pharo-9.0.0+build.345.sha.1604382b75d9ef6dd755473fa4262e087ad4ba05 (64 Bit)

Expected development cost
?

Additional context
crash.dmp.txt

hogoww added a commit to hogoww/opensmalltalk-vm that referenced this issue Dec 23, 2021
… ] on method [ countNumClassPagesPreSwizzle: ]
hogoww added a commit to hogoww/opensmalltalk-vm that referenced this issue Dec 23, 2021
…] on method [ countNumClassPagesPreSwizzle: ] KILLED by 1/209 test cases.
hogoww added a commit to hogoww/opensmalltalk-vm that referenced this issue Dec 29, 2021
hogoww added a commit to hogoww/opensmalltalk-vm that referenced this issue Dec 29, 2021
…d [ fetchClassOfNonImm: ] KILLED by 1/234 test cases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants