Vcpkg: libffi:x86-windows crashes since update to version 3.3 on february 7th

[rglbssw]

Describe the bug
I install gtkmm:x86-windows for use in an application. everything worked fine. But with commit 7d4227f02e445b0a29f8c1ce3258b57d60b71cfe libffi was upgraded to version 3.3. Since then my application crashes on every mouse click when returning from libffi assembler code (see debugger screenshot under "Failure Logs" below).
I assume, it has to do with the target x86-windows. The libffi src folder does not contain a "win32.S" file any more, only a "win64.S"!

Environment

• OS: Windows 10 Enterprise
• Compiler: Visual Studio Professional 2019 16.4.5

To Reproduce
Steps to reproduce the behavior:

1. ./vcpkg install gtkmm:x86-windows
2. build an application using gtkmm
3. click with mouse

I think it does not depend on gtkmm. I'm sure, a GTK3-application would also crash.

Expected behavior
I would expect no crash. This was the behaviour with libffi 3.1

Failure logs
Debugger screenshot

Additional context
The contents of the file vcpkginstalledstatus:

installed-status.txt

[itayzafrir]

I'm also having a similar issue but with GTK in a 64bit build:

OS: Windows 10 x64
GTK: 3.22.2-2

Everything works fine in a release build, but when running a debug build I get a runtime error as soon as the application starts up.
The error is in function ffi_call_win64 which is called from ffi_call_int.

Screenshot:

[feliwir]

Having the same issue here when using Gtk

[feliwir]

Any updates on this? This is a complete blocker for debugging my application

[NancyLi1013]

Hi all,
Sorry for the late reply. I will check this issue later.
Could you please help confirm if this can work well before libffiupdaed to 3.3?

[feliwir]

@NancyLi1013 how can i install the older library version?

[NancyLi1013]

You can use git checkout commit id to checkout a new branch to the commit that the older library version was updated.

Could you please also help provide the project case?

[itayzafrir]

Any updates on this? This is a complete blocker for debugging my application

If you don't need to debug libffi then you can use the release build of it. That's what I did for now, just copied the release version and overwrote it in my app's output directory

[rglbssw]

This may be helpful in your actual painful situation. But it will not help to fix the general problem.
So please - in addition to this work around - follow Nancy's advice. If your application does not depend on newly added or modified packages it is not too hard. I myself did the following:

• clone a new copy of vcpkg
• create a new local branch from a commit before the commit commented "[libffi] Update to v3.3 release (#6119)". I decided to use the commit 7aebb481085de7387f8a9975652c26f9053f66df labeled "2020.01".
• switch to the newly created branch
• vcpkg install gtkmm (and libxmlpp because I need it for my application). Maybe you only need to install gtk.
• rebuild the application (debug version) using the newly created packages.
• try running it.
  In my case, the difference ist obvious.

[rglbssw]

Here are two minimal example applications to reproduce the behavior. One is for gtk, the other one is for gtkmm. The msvs vcxproj... and props files provided with the two examples allow you to test debug and release builds for 32 and 64 bit windows. You should unpack the two zip files to the directory where your vcpkg directory resides. this will lead to a directory layout like that:

• GtkmmSampleForVcpkg
• GtkSampleForVcpkg
• vcpkg

The GtkmmSample presupposes, that you vcpkg install gtkmm for the target platforms you want to build and test. To build and test the GtkSample only vcpkg install gtk is needed.

I've tested all variants with both libffi 3.3 (commit 7d4227f02e445b0a29f8c1ce3258b57d60b71cfe) and libffi 3.1 (the commit immediately before 8eaa597bba70728c70feb4674566abcbe6feeb5c).
Both example apps crash in the debug builds with libffi 3.3 on both target platforms.

Hope this helps solving the issue.

GtkmmSampleForVcpkg.zip
GtkSampleForVcpkg.zip

[NancyLi1013]

@rglbssw

Thanks for your update and detail information about this issue.
I will try to reproduce according to the projects you provided above.

[NancyLi1013]

@rglbssw
I have tested and this issue can be reproduced on my local now.
It seems that this issue is only happened in debug type.
We will go further investigation about this.

[feliwir]

@NancyLi1013 yes it only happens in debug builds as @itayzafrir mentioned. Great you can reproduce this now!

[764994703]

@NancyLi1013 it seems that in x86-windows debug mode, in function ffi_call_int, call to _alloca leads to a failure in _RTC_CheckStackVars2, because %rsp is recovered when the ffi_call_int function return, which is after call to _RTC_CheckStackVars2. avoid using _alloca can help.

[NancyLi1013]

@764994703
Thanks for your deep investigation about this.
We will try to look into it.

[JackBoosY]

I think that's a Visual Studio bug.

[pim01]

Following the suggestions of @rglbssw and @NancyLi1013 I checkout to the commit tagged 2020.01 where libffi:x64-windows 3.1-7 is installed. I do confirm that the .exe executes normally in debug mode with this version of the library. In the older version libbffi was installed as a static library only (and so there is no export of the dll into the application's directory), whereas in the newer version 3.3-2 libffi is installed as both static and dynamic. May be a workaround would be to compile libffi 3.3-2 as a static lib only ?

[driver1998]

Following the suggestions of @rglbssw and @NancyLi1013 I checkout to the commit tagged 2020.01 where libffi:x64-windows 3.1-7 is installed. I do confirm that the .exe executes normally in debug mode with this version of the library. In the older version libbffi was installed as a static library only (and so there is no export of the dll into the application's directory), whereas in the newer version 3.3-2 libffi is installed as both static and dynamic. May be a workaround would be to compile libffi 3.3-2 as a static lib only ?

Allowing shared DLL is needed because vcpkg only supports dynamic DLL on Windows ARM. (insane, I know) We should be able to let it build only static lib on x86/x64.

[nikoqw]

I have the same issue when using gtkmm

[Ajax-Light]

Yep, experiencing the same issue. Had to run my College Project in release mode to avoid this. The libffi call is optimized away in release mode (resulting in a lot less assembly code) and also does not corrupt the stack. Maybe a memory allocation / re-allocation issue as @764994703 said.. I gave up trying to figure out the root cause... glad I found this thread !!

[Zergoma]

hello

I've got the same problem
Windows 7 pro
Visual Studio 2019 Community
x64
debug mode

soo sad ... I really hope a fix

[Zergoma]

hello

I'm surprized: dependency walker seems to find that the vcruntime is ... 140 Oo' (for both, release [who is working] and debug)
Is that normal ? I expected something like 142 to be honest for vs2019 ... [sorry if I say something stupid]
Is that related for the crash or nothing at all ?

[NancyLi1013]

Hi all,
Could you please rebuild this based on the PR #12498 from @Mixaill ?
After disabling runtime stack check for libffi, I cannot reproduce this issue on my local now.

[ice0]

@NancyLi1013 just checked on my own project - all works fine!

[rglbssw]

Works fine for x64-windows. I tried to extend the solution for x86-windows (see https://github.com/microsoft/vcpkg/pull/12498#issuecomment-662498095).

[Ajax-Light]

[Newbie Question]: Shouldn't we find out what caused the Stack Corruption instead of disabling the Runtime Check? I don't mean to offend / belittle the work done by @Mixaill and @rglbssw , but I would like to know what caused the Stack to be corrupted in the first place.

According to Microsoft Docs, one of the reasons /RTC fails is due to a calling convention mismatch. I have tried setting different calling conventions like _stdcall or _cdecl , but the crash persists. The other reasons include overruns / under-runs of memory; Padding issues with Struct Member Alignment ( /Zp ), which I am currently looking into..

[JackBoosY]

@Ajax-Light It's a Visual Studio bug.

[Mixaill]

Shouldn't we find out what caused the Stack Corruption instead of disabling the Runtime Check?

It is the intended behavior for libffi, it modfies stack of the caller function which results in RTC trigger. No actual error here.

[Ajax-Light]

Ah! I understand now. Thanks for your time. 👍

[rglbssw]

Thanks to all at any place!
Especially I'd like to praise:
@Mixaill who broke the Gordian knot
and @NancyLi1013 who tamed the wild blue bot
in its azure pipeline maze.

(... e grazie a la @strega-nil)

[WinformsWizard]

It is still happening for me, do I need to do something to apply the fix?

[rglbssw]

Seems as if the patch was not applied already. The code would look a bit different, if it was.
Did you do a "vcpkg upgrade" after pulling?
If you tried the pull request before it was merged, especially if you did that before it contained the x86-windows patch, it is possible, that vcpk doesn't recognize the package as outdated. In this case you should vcpkg remove the package and vcpkg install it again. If vcpkg decides to restore it from a cached version, delete the cached version and try it again.

[faserg1]

Have installed with gtkmm as root package. Same issue. x64-windows.
UPD: Installed vcpkg as submodule, so I have to git submodule update --init --recursive --remote. Now should work.