The application program of MinGW compiling platform uses libcef.dll, when calling the capi interface of CEF, the program crashes. When debugging a single step to the CEF capi function, the debugger will report an error “cannot find boundaries of current function”

How to solve the problem https://stackoverflow.com/questions/8741493/why-i-do-get-cannot-find-bound-of-current-function-when-i-overwrite-the-ret-ad

In Windows platform, we need to use embedded browser CEF and C + + 11 at the same time, and we don’t want to install huge vs development environment. Codeblocks-17.12mingw-nosetup is selected as the starting environment, the compressed package is less than 100MB, and MinGW GCC is version 5.1.0 of 2015. The VC compiler supporting the same C + + 11 features should be vs2015, even the express version has 5g

http://opensource.spotify.com/cefbuilds/index.html#windows32_ Builds found the lowest version of libcef.3.2704.1414, about 50m in size. I found a smaller volume in other software, only 40m libcef.dll.3.2171. If you are not infatuated with C + + wrapper, you can use capi directly after downloading cefbuild. If you’re used to & lt& lt; inside c++ object model>> In fact, the CEI of CEF has been designed with object-oriented thinking

With the development environment CodeBlocks + MinGW, the ready-made library file libcef.dll.3.2171, and the interface header file libcef.3.2704.1414.zip. As long as the library file of Win32 is converted to the link library of MinGW, it can be used. Naturally, we use MinGW’s tools to export def, and then export the. A library file

After adjusting the configuration, the program compiles and links successfully, but fails to run. When debugging, GCC reports an error “cannot find boundaries of current function” when running CEF capi

This error is not that the library file is not loaded or the function is not loaded, but the function boundary problem. There is a post discussion in stackoverflow to answer “it covers the currentstack frame of your function with relevant data, and destroys the return address in the process, which is normally stored there along other things”. The stack frame of the function call is broken. This is a common problem in the development of WIN platform. Who is responsible for balancing the stack between stdcall and cdecl, callee and caller?If they are inconsistent, the stack frame will be destroyed. WinAPI and callpack are stdcall. But the CEF project has such a CEF_ Callpack is the callback Convention under win operating platform, which is naturally stdcall. The early CEF project (3.27xx adopted in this paper in 2016) did not consider the support for MinGW, and there were only two branches of compiler in precompile_ MSVC and compiler_ GCC, the weird thing is that MinGW is GCC on winos, so it’s very embarrassing. The latest version of CEF will be CEF_ Callpack is defined separately in a precompiled branch OS_ WIN。

CEF_ Callpack is defined in internal/CEF_ export.h。 Compare the following two versions of the file:

3.2704.1414

#if defined(COMPILER_MSVC)

#ifdef BUILDING_CEF_SHARED
#define CEF_EXPORT __declspec(dllexport)
#elif USING_CEF_SHARED
#define CEF_EXPORT __declspec(dllimport)
#else
#define CEF_EXPORT
#endif
#define CEF_CALLBACK __stdcall

#elif defined(COMPILER_GCC)

#define CEF_EXPORT __attribute__ ((visibility("default")))
#define CEF_CALLBACK

#endif  // COMPILER_GCC

#endif  // CEF_INCLUDE_INTERNAL_CEF_EXPORT_H_

78.3.9

#if defined(COMPILER_MSVC)

#ifdef BUILDING_CEF_SHARED
#define CEF_EXPORT __declspec(dllexport)
#elif USING_CEF_SHARED
#define CEF_EXPORT __declspec(dllimport)
#else
#define CEF_EXPORT
#endif

#elif defined(COMPILER_GCC)

#define CEF_EXPORT __attribute__((visibility("default")))

#endif  // COMPILER_GCC

#if defined(OS_WIN)
#define CEF_CALLBACK __stdcall
#else
#define CEF_CALLBACK
#endif

The problem is solved