Project

General

Profile

Bug #15348

r66003 Support targetting TracePoint - MinGW

Added by MSP-Greg (Greg L) 6 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:90094]

Description

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...

Associated revisions

Revision 66e9bfd4
Added by ko1 (Koichi Sasada) 6 months ago

use __builtin_setjmp on mingw64 [Bug #15348].

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66087 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 66087
Added by ko1 (Koichi Sasada) 6 months ago

use __builtin_setjmp on mingw64 [Bug #15348].

Revision 66087
Added by ko1 (Koichi Sasada) 6 months ago

use __builtin_setjmp on mingw64 [Bug #15348].

History

Updated by ko1 (Koichi Sasada) 6 months ago

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, Greg.mpls@gmail.com 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

Updated by MSP-Greg (Greg L) 6 months ago

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

Updated by MSP-Greg (Greg L) 6 months ago

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

#4

Updated by ko1 (Koichi Sasada) 6 months ago

  • Status changed from Open to Closed

Applied in changeset trunk|r66087.


use __builtin_setjmp on mingw64 [Bug #15348].

Also available in: Atom PDF