Segmentation Fault in P9

[tinchodias]

1. Download Pharo 9 this way: curl https://get.pharo.org/64/90+vmHeadlessLatest | bash
2. Follow default loading instructions, enable in settings, and save&quit.
3. Try to re open with pharo-ui.
4. Get:

Segmentation fault Thu Feb 25 15:39:10 2021


/private/tmp/scg/pharo-vm/Pharo.app/Contents/MacOS/Pharo
PharoVM version:5.0-Pharo 9.0.0 built on Feb 23 2021 14:17:07 Compiler: 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.29) 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.29) [Production Spur 64-bit VM]
Built from: CoInterpreter VMMaker-tonel.1 uuid: cd319970-6278-0d00-8cf8-14330fc78c75 Feb 23 2021
 With:StackToRegisterMappingCogit VMMaker-tonel.1 uuid: cd319970-6278-0d00-8cf8-14330fc78c75 Feb 23 2021
 Revision: a3a0902b - Commit: a3a0902b - Date: 2021-02-23 13:50:44 +0100

C stack backtrace & registers:
	rax 0x0000000000000000 rbx 0x0000000114f39e30 rcx 0x0000000000000eb4 rdx 0x000000010a089e90
	rdi 0x0000000000000005 rsi 0x0000000000000005 rbp 0x00007ffee5c5a410 rsp 0x00007ffee5c5a3e0
	r8  0x000000010a06480e r9  0x000000010a064812 r10 0x0000000000000000 r11 0x0000000000000000
	r12 0x00007ffee5c6a0e8 r13 0x0000000000000000 r14 0x000000010f840440 r15 0x000000010a07c070
	rip 0x000000010f840455
*0   libSurfacePlugin.dylib              0x000000010f840455 primitiveCreateManualSurface + 21
1   libPharoVMCore.dylib                0x000000010a05f7c9 reportStackState + 313
2   libPharoVMCore.dylib                0x000000010a05f667 doReport + 183
3   libPharoVMCore.dylib                0x000000010a06034d sigsegv + 77
4   libsystem_platform.dylib            0x00007fff203a1d7d _sigtramp + 29
5   ???                                 0x0000000000000000 0x0 + 0
6   libPharoVMCore.dylib                0x000000010a00aa17 primitiveExternalCall + 951
7   libPharoVMCore.dylib                0x0000000109ff45b0 interpret + 29840
8   libPharoVMCore.dylib                0x000000010a0002f5 enterSmalltalkExecutiveImplementation + 149
9   libPharoVMCore.dylib                0x0000000109fed788 interpret + 1640
10  libPharoVMCore.dylib                0x0000000109fa5696 vm_main_with_parameters + 710
11  libPharoVMCore.dylib                0x0000000109fa57f6 vm_main + 294
12  Pharo                               0x0000000109f96f24 start + 52
13  ???                                 0x0000000000000000 0x0 + 0

Can't dump Smalltalk stack(s). Not in VM thread

Most recent primitives
stringHash:initialHash:
stringHash:initialHash:

[tinchodias]

PharoDebug.log

[ronsaldo]

This bug is much weirder than what I thought. If I perform FormSGAthensWorldMorph new open in a normal P9 image it works. But if I enable it by default it fails, even if I use a different renderer. This seems to be related to the threaded ffi change.

[ronsaldo]

This is a VM bug. I just found a workaround for it, which I have just committed. The workaround was to add the following initialize method:

FormAthensSGWorldRenderer >> initialize
initialize
	super initialize.
	
	self flag: 'FIXME: workaround a VM bug. The SurfacePlugin defines methods that are called via primitives and the FFI. If these methods are called first via the FFI, the plugin module is never initialized which causes a segmentation fault by not setting the interpreter proxy in the plugin. We create an OSSDL2ExternalForm here to to avoid this border case.'.
	OSSDL2ExternalForm extent: 1@1 depth: 32 bits: ExternalAddress null.

The bug is present in the following function in sqNamedPrims.c (@guillep , @tesonep) :

static ModuleEntry *
findAndLoadModule(char *pluginName, sqInt ffiLoad)
{
	void *handle;
	ModuleEntry *module;

	if (!moduleLoadingEnabled)
		return NULL;

	logTrace("Looking for plugin %s\n", (pluginName ? pluginName : "<intrinsic>"));
	/* Try to load the module externally */
	handle = ioLoadModule(pluginName);
	if(ffiLoad) {
		/* When dealing with the FFI, don't attempt to mess around internally */
		if(!handle) return NULL;
		return addToModuleList(pluginName, handle, ffiLoad);
	}
	/* NOT ffiLoad */
	if(!handle) {
		/* might be internal, so go looking for setInterpreter() */
		if(findInternalFunctionIn("setInterpreter", pluginName, 0, 0))
			handle = squeakModule->handle;
		else
			return NULL; /* PluginName_setInterpreter() not found */
	}
	module = addToModuleList(pluginName, handle, ffiLoad);
	if(!callInitializersIn(module)) {
		/* Initializers failed */
		if(handle != squeakModule->handle) {
			/* physically unload module */
			ioFreeModule(handle);
		}
		removeFromList(module); /* remove list entry */
		free(module); /* give back space */
		module = NULL;
	}
	return module;
}

It seems that the module should be always initialized if it exposes the functions to initialize the primitive methods. This bug is triggered by invoking AthensCairoSurface >> asForm before an OSSDL2ExternalForm is ever created. I also noticed that AthensCairoSurface is using callbacks for registering with the external surface machinery. This usage of callback here in my opinion is overkill since the AthensCairoSurface does not change its extent, and the pointer returned by AthensCairoSurface >> #getDataPtr is constant for the CPU only surfaces that we are currently using, and it also introduces scheduling timing bugs (in one occasion I was not able to restart my image because I got an error complaining of a callback that cannot return).

[Ducasse]

Thanks Ronie!

[tinchodias]

I didn't have any problem now in P9, but I let you close the issue.

[tinchodias]

May be another issue:
I did have segfault in P9 after loading this extra code:

Metacello new
   baseline: 'FormSceneGraph';
   repository: 'github://ronsaldo/form-scene-graph';
   load: #AcceleratedOpenGL.

• enable in settings and select OpenGL renderer + save and quit

Dmp:

crash.dmp.txt

[tinchodias]

Two more things:

1. I was working here:

2. The "AcceleratedAbstractGPU" worked fine.