Module crashes on MacOS and kills session

[acsanyi]

Version 0.4.11 of this module causes a stack overflow on Mac systems and kills the active PowerShell session. The module doesn't even need to be used; simply importing it into a PowerShell session will invoke the problem.
Here's the exception: exception.txt

Affected systems

(Note these are just the ones we were able to test on):

• MacOS 14.7 on M2 Pro
• MacOS 15.2 on M2 Pro
• MacOS 15.2 on M3 Pro

This happens on PS Core 7.4.5 and 7.4.6.

How to reproduce

Import the module into the current PowerShell session

Import-Module powershell-yaml

Then just wait. The crash should occur within a few minutes, but it seems to vary from system to system.

Additonal testing

I see this module uses two .Net DLLs, but manually loading them using [Reflection.Assembly]::LoadFile() doesn't have an effect, so I can only assume there's something else going on in the .psm1 file that's causing this.

[gabriel-samfira]

Hi @acsanyi

I have a hunch that this is caused by:

powershell-yaml/powershell-yaml.psm1

Lines 45 to 55 in 18c7894

	[System.AppDomain]::CurrentDomain.add_AssemblyResolve({
	param ($snd, $e)
	# Load YamlDotNet if it's requested by PowerShellYamlSerializer. Ignore other requests as they might
	# originate from other assemblies that are not part of this module and which might have different
	# versions of the module that they need to load.
	if ($e.Name -like "*YamlDotNet*" -and $e.RequestingAssembly -like "*PowerShellYamlSerializer*" ) {
	return [System.Reflection.Assembly]::LoadFile($powershellYamlDotNetAssemblyPath)
	}
	return $null
	})

Which tries to resolve the YamlDotNet.dll assembly when the PowerShellYamlSerializer.dll needs it. The if statement is a bit broad. If you have other assemblies that have installed AssemblyResolvers and the powershell-yaml one gets loaded before those and the if statement accidentally matches something that the other assemblies require, it may return YamlDotNet when in reality they require an entirely different assembly.

This is just a guess on my side, but I have opened a PR here:

• Fix potential erroneous load of assembly #180

Could you check if this still happens in your env with the above PR?

[gabriel-samfira]

The PR now removes the AssemblyResolver once we've loaded the assembly and made sure it triggered the load of YamlDotNet. So there should not be any handler left over for the duration of the session.

[gabriel-samfira]

CC @RokeJulianLockhart

Is this issue similar to what you've seen?

[RokeJulianLockhart]

#179 (comment)

@gabriel-samfira, yeah, that's exactly it. I've just reproduced it by running Import-Module powershell-yaml and waiting approximately 2 minutes. You can see a new gnome-abrt (adb?) trace for it at bugzilla.redhat.com/show_bug.cgi?id=2333966#c12, and a shell trace at gist.github.com/RokeJulianLockhart/d588a9a1972aaec43006f7656e9878bb.

Posted to PowerShell/discussions/24701#discussioncomment-11923442.

[gabriel-samfira]

#179 (comment)

@gabriel-samfira, yeah, that's exactly it. I've just reproduced it by running Import-Module powershell-yaml and waiting approximately 2 minutes. You can see a new gnome-abrt (adb?) trace for it at bugzilla.redhat.com/show_bug.cgi?id=2333966#c12, and a shell trace at gist.github.com/RokeJulianLockhart/d588a9a1972aaec43006f7656e9878bb.

Posted to PowerShell/discussions/24701#discussioncomment-11923442.

Can you try out #180 and see if it still happens?

[RokeJulianLockhart]

#179 (comment)

@gabriel-samfira, IDK... For all I do know, I'm not familiar with running most things unpackaged.

• If you're confident enough that it's a solution to upload it to a PowerShell Gallery release, I can. However, that's obviously a very slow feedback loop.

• Alternatively, if there's an installation file I can locally import to test (a bit like building an RPM file in GH CI, instead of via an distro repository) I can do that.

Apologies if that's of no use.

[gabriel-samfira]

@RokeJulianLockhart

git clone https://github.com/gabriel-samfira/powershell-yaml
cd powershell-yaml
git checkout potentially-fix-overflow

In the same folder enter into a new powershell session:

pwsh

And import the module from the cloned repo:

Import-Module ./powershell-yaml.psd1

[RokeJulianLockhart]

#179 (comment)

@gabriel-samfira, I checked out 01b1b468e1e1d539d5fcaa7fd7e161f15c01f79f, and it doesn't appear to have yet, after waiting >11 minutes:

Script started, output log file is 'typescript'.
RokeJulianLockhart@SNRW3Q:~/Documents/PowerShellYAML$ git clone https://github.com/gabriel-samfira/powershell-yaml
cd powershell-yaml
git checkout potentially-fix-overflow
Cloning into 'powershell-yaml'...
remote: Enumerating objects: 784, done.
remote: Counting objects: 100% (92/92), done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 784 (delta 61), reused 55 (delta 48), pack-reused 692 (from 2)
Receiving objects: 100% (784/784), 2.42 MiB | 3.56 MiB/s, done.
Resolving deltas: 100% (401/401), done.
branch 'potentially-fix-overflow' set up to track 'origin/potentially-fix-overflow'.
Switched to a new branch 'potentially-fix-overflow'
RokeJulianLockhart@SNRW3Q:~/Documents/PowerShellYAML/powershell-yaml$ pwsh
PowerShell 7.4.6
PS /home/RokeJulianLockhart/Documents/PowerShellYAML/powershell-yaml> Import-Module ./powershell-yaml.psd1
PS /home/RokeJulianLockhart/Documents/PowerShellYAML/powershell-yaml>

I'd say it seems solved. I'll leave the shell open to be certain.

[acsanyi]

Wow, thank you for the quick turnaround on this everyone! As I'm on Windows I can't verify but I'll get my Mac colleagues to verify this today. 😊

[acsanyi]

My Mac colleagues have confirmed the fix works! Thank you!
When do you think a new release will be available?

[gabriel-samfira]

A new version has been published: https://www.powershellgallery.com/packages/powershell-yaml/0.4.12