Bug #15348: r66003 Support targetting TracePoint - MinGW

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 2.4: UNKNOWN, 2.5: UNKNOWN

[MSP-Greg (Greg L)]

This has caused failures in spec/ruby/core/main/using_spec.rb, specifically the first spec.

On Appveyor, trying several versions of both specs, the first one (eval('using', TOPLEVEL_BINDING)) fails, the second one (eval('using "foo"', TOPLEVEL_BINDING)) passes.

Locally (Windows 10), all versions of both specs have always passed using the same build (saved as an artifact) from Appveyor...

[ko1 (Koichi Sasada)]

On my msys2 environment, it hits!

On my environemnt,

using

only this script hangs.

And I found these articles:

http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html

Following the thread’s advice, I was able to work around the issue by
using the compiler’s built-in functions __builtin_setjmp and
__builtin_longjmp instead of setjmp and longjmp. These seem to be
alternative implementations included in GCC which don’t call msvcrt.dll.
The downside is that the __builtin functions are GCC-specific and not
technically user-facing. They could change in any release. But using the
built-in functions did fix the crash bug, and now exception handling is
working correctly in my project.

https://sourceforge.net/p/mingw-w64/bugs/406/

https://github.com/antoniovazquezblanco/nspire_emu uses setjmp and
longjmp (emu.c) and crashes when used in a 64bit windows environment
because setjmp sets the stack register value to 0x10. Using
__builtin_setjump avoids the problem because the stack register doesn't
get messed (doesn't seem to call setjmp3 function of the
C:\Windows\SysWOW64\msvcrt.dll library).

I changed config.h to

#define RUBY_SETJMP(env) __builtin_setjmp((env))
#define RUBY_LONGJMP(env,val) __builtin_longjmp((env),val)

and this test passes!!!

I'm not sure it is correct way, but could you try it?

Thanks,
Koichi

On 2018/11/28 4:42, [e-mail] wrote:

Issue #15348 has been reported by MSP-Greg (Greg L).

---

Bug #15348: r66003 Support targetting TracePoint - MinGW
https://bugs.ruby-lang.org/issues/15348

• Author: MSP-Greg (Greg L)
• Status: Open
• Priority: Normal
• Assignee:
• Target version:
• ruby -v:
• Backport: 2.4: UNKNOWN, 2.5: UNKNOWN

---

This has caused failures in spec/ruby/core/main/using_spec.rb, specifically the first spec.

On Appveyor, trying several versions of both specs, the first one (eval('using', TOPLEVEL_BINDING)) fails, the second one (eval('using "foo"', TOPLEVEL_BINDING)) passes.

Locally (Windows 10), all versions of both specs have always passed using the same build (saved as an artifact) from Appveyor...

--
// SASADA Koichi at atdot dot net

[MSP-Greg (Greg L)]

@ko1 (Koichi Sasada) Koichi,

Thank you. Repeat that. ruby-loco is green.

Going back to last year, I've had intermittent (and sometimes only on appveyor) issues with callcc, the (sometimes considerable) block nesting in the spec suite, and this issue, in which nesting, eval, and maybe using all came together.

I finally created a repo so I could do 'custom testing' without building just to see what was going on, as I mentioned, I couldn't repo this locally.

Again, thanks, Greg

[MSP-Greg (Greg L)]

@ko1 (Koichi Sasada) Koichi,

I did another ruby-loco build, and it also passed. The 'test repo' I did is here:

https://ci.appveyor.com/project/MSP-Greg/ruby-loco-test/history

Currently it runs three versions of the failing specs. In the first build, done before your fix, two of the three versions silent SEGV'd, and the third failed. The four builds (#2 thru #5) were done after the fix, all three versions passed in each. IOW, your fix certainly seems solid.

@k0kubun (Takashi Kokubun)

When Appveyor is slow, it's very common for one or more TestJIT tests to fail running parallel but pass on retry. I've found the total build time (not test), along with the bootstraptest time are good indicators of how well test-all will go (or how busy Appveyor is).

Both of the 'post-fix' ruby-loco builds completed TestJIT when running parallel.

The second build was slow for both 'indicators', but TestJIT still had no parallel failures.

Thought I'd mention it, as I know you've wrestled with intermittent test issues on mingw/mswin...

Thanks to both of you for your work, Greg

[ko1 (Koichi Sasada)]

• Status changed from Open to Closed

Applied in changeset trunk|r66087.

---

use __builtin_setjmp on mingw64 [Bug #15348].