[ruby-core:90094] [Ruby trunk Bug#15348] r66003 Support targetting TracePoint - MinGW

[ruby-core:90094] [Ruby trunk Bug#15348] r66003 Support targetting TracePoint - MinGW

[Greg.mpls]

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



-- 
https://bugs.ruby-lang.org/

[ruby-core:90127] Re: [Ruby trunk Bug#15348] r66003 Support targetting TracePoint - MinGW

[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, 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

[ruby-core:90132] [Ruby trunk Bug#15348] r66003 Support targetting TracePoint - MinGW

[Greg.mpls]

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


@ko1  Koichi,

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

Going back to last year, I've have 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 tesing' without building just to see what was going on, as I mentioned, I couldn't repo this locally.

Again, thanks, Greg







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

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



-- 
https://bugs.ruby-lang.org/

[ruby-core:90138] [Ruby trunk Bug#15348] r66003 Support targetting TracePoint - MinGW

[Greg.mpls]

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


@ko1 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

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


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

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



-- 
https://bugs.ruby-lang.org/