[#32009] merging nokogiri to ext/ — Aaron Patterson <aaron@...>

I would like to merge nokogiri to ext for the 1.9.3 release. I spoke to

82 messages 2010/09/02
[#32010] Re: merging nokogiri to ext/ — "U.Nakamura" <usa@...> 2010/09/02

Hello,

[#32012] Re: merging nokogiri to ext/ — Ryan Davis <ryand-ruby@...> 2010/09/02

[#32030] Re: merging nokogiri to ext/ — "NARUSE, Yui" <naruse@...> 2010/09/03

Hi,

[#32033] Re: merging nokogiri to ext/ — "NARUSE, Yui" <naruse@...> 2010/09/03

2010/9/3 NARUSE, Yui <naruse@airemix.jp>:

[#32155] Re: merging nokogiri to ext/ — Yusuke ENDOH <mame@...> 2010/09/08

Currently, we're discussing three different topics:

[#32189] Re: merging nokogiri to ext/ — Aaron Patterson <aaron@...> 2010/09/09

On Thu, Sep 09, 2010 at 01:40:34AM +0900, Yusuke ENDOH wrote:

[#32056] [Ruby 1.8-Bug#3788][Open] URI cannot parse IPv6 addresses propertly — Adam Majer <redmine@...>

Bug #3788: URI cannot parse IPv6 addresses propertly

16 messages 2010/09/04

[#32110] Ruby 2.0 Wiki/Wish-list? — Joshua Ballanco <jballanc@...>

Hi all,

41 messages 2010/09/07
[#32114] Re: Ruby 2.0 Wiki/Wish-list? — "NARUSE, Yui" <naruse@...> 2010/09/08

2010/9/8 Joshua Ballanco <jballanc@gmail.com>:

[#32117] Re: Ruby 2.0 Wiki/Wish-list? — Joshua Ballanco <jballanc@...> 2010/09/08

On Sep 7, 2010, at 5:21 PM, NARUSE, Yui wrote:

[#32143] Re: Ruby 2.0 Wiki/Wish-list? — Roger Pack <rogerdpack2@...> 2010/09/08

> So, for example, a few things I've wanted for a long time:

[#32135] [Ruby-Bug#3802][Open] freeaddrinfo not found in WS2_32.dll — Thomas Volkmar Worm <redmine@...>

Bug #3802: freeaddrinfo not found in WS2_32.dll

16 messages 2010/09/08

[#32154] Making custom_lambda() work — Magnus Holm <judofyr@...>

A tiny suggestion for how we could make it possible to call lambdas

15 messages 2010/09/08
[#32159] Re: Making custom_lambda() work — Nikolai Weibull <now@...> 2010/09/08

On Wed, Sep 8, 2010 at 18:21, Magnus Holm <judofyr@gmail.com> wrote:

[#32156] Can we convert the standard library to gems? — James Edward Gray II <james@...>

Taken from the bundle Nokogiri thread:

98 messages 2010/09/08
[#32161] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/08

On 2010-09-09 01:45:43 +0900, James Edward Gray II wrote:

[#32166] Re: Can we convert the standard library to gems? — James Edward Gray II <james@...> 2010/09/08

On Sep 8, 2010, at 12:03 PM, Marcus Rueckert wrote:

[#32173] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/08

On 2010-09-09 02:54:26 +0900, James Edward Gray II wrote:

[#32249] Re: Can we convert the standard library to gems? — Aaron Patterson <aaron@...> 2010/09/09

On Thu, Sep 09, 2010 at 05:26:54AM +0900, Marcus Rueckert wrote:

[#32278] Re: Can we convert the standard library to gems? — Lucas Nussbaum <lucas@...> 2010/09/10

On 10/09/10 at 02:41 +0900, Aaron Patterson wrote:

[#32162] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/08

Hi,

[#32216] Re: Can we convert the standard library to gems? — Ryan Davis <ryand-ruby@...> 2010/09/09

[#32229] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/09

Hi,

[#32260] Re: Can we convert the standard library to gems? — Ryan Davis <ryand-ruby@...> 2010/09/09

[#32275] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/10

I'm off today so sorry if I missed some mails.

[#32293] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/10

Urabe,

[#32316] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/11

(2010/09/10 23:48), James Cox wrote:

[#32322] Re: Can we convert the standard library to gems? — James Tucker <jftucker@...> 2010/09/11

[#32335] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/12

I'm at an airport back to my home so in short,

[#32343] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/12

On Sun, Sep 12, 2010 at 6:51 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wr=

[#32382] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/14

(2010/09/13 3:54), James Cox wrote:

[#32383] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/14

On Tue, Sep 14, 2010 at 12:37 PM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#32393] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/15

How difficult to make myself understood in English.

[#32396] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 1:43 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wr=

[#32399] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/15

Hi,

[#32400] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 12:07 PM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:

[#32401] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/15

On 2010-09-16 01:42:39 +0900, James Cox wrote:

[#32402] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 1:35 PM, Marcus Rueckert <darix@opensu.se> wrote:

[#32411] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/15

On 2010-09-16 03:36:56 +0900, James Cox wrote:

[#32412] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/16

On Wednesday, September 15, 2010, Marcus Rueckert <darix@opensu.se> wrote:

[#32414] Re: Can we convert the standard library to gems? — Lucas Nussbaum <lucas@...> 2010/09/16

On 16/09/10 at 11:02 +0900, James Cox wrote:

[#32248] Replacing stdlib Date with C version — Jeremy Evans <code@...>

I've recently been working on a replacement for the stdlib Date class,

15 messages 2010/09/09

[#32290] [Ruby 1.9.2-Backport#3818][Open] Seg fault with ruby tmail and ruby 1.9.2 — Karl Baum <redmine@...>

Backport #3818: Seg fault with ruby tmail and ruby 1.9.2

10 messages 2010/09/10

[#32453] Why doesn’t Enumerable define a #last method? — Nikolai Weibull <now@...>

Hi!

9 messages 2010/09/17

[#32454] [Ruby 1.9-Feature#3845][Open] "in" infix operator — Yusuke Endoh <redmine@...>

Feature #3845: "in" infix operator

20 messages 2010/09/17
[#32489] Re: [Ruby 1.9-Feature#3845][Open] "in" infix operator — Benoit Daloze <eregontp@...> 2010/09/21

On 17 September 2010 12:30, Yusuke Endoh <redmine@ruby-lang.org> wrote:

[#32529] [Ruby 1.9-Bug#3869][Open] Logger#log does not handle or escape new-line characters. — Hal Brodigan <redmine@...>

Bug #3869: Logger#log does not handle or escape new-line characters.

9 messages 2010/09/23

[#32585] Proposal for Optional Static Typing for Ruby — Martin Pilkington <pilky@...>

Hi,

47 messages 2010/09/27
[#32588] Re: Proposal for Optional Static Typing for Ruby — Yukihiro Matsumoto <matz@...> 2010/09/27

Hi,

[#32592] Re: Proposal for Optional Static Typing for Ruby — Martin Pilkington <pilky@...> 2010/09/28

Hi Matz

[#32595] Re: Proposal for Optional Static Typing for Ruby — Asher <asher@...> 2010/09/28

Martin,

[#32611] Re: Proposal for Optional Static Typing for Ruby — Loren Segal <lsegal@...> 2010/09/28

Hi,

[#32628] Re: Proposal for Optional Static Typing for Ruby — Eleanor McHugh <eleanor@...> 2010/09/29

It strikes me that much of the premise behind this thread is misguided =

[#32634] [Ruby 1.9-Bug#3889][Open] Incorrectly detected i686-w64-mingw32 as x64-mingw — Luis Lavena <redmine@...>

Bug #3889: Incorrectly detected i686-w64-mingw32 as x64-mingw

21 messages 2010/09/29

[ruby-core:32557] [Ruby 1.9-Feature#3875] [Patch] backtrace for i386-mswin32_100

From: Peter Weldon <redmine@...>
Date: 2010-09-25 17:59:17 UTC
List: ruby-core #32557
Issue #3875 has been updated by Peter Weldon.

File 0002-Add-C-level-backtrace-for-MSWIN-x86.patch added

> * why StackWalk64 instead of StackWalk?

StackWalk64 supersedes StackWalk in the newer Windows SDKs and has suppor=
t for x64.

> * why does it need another thread?

It most probably doesn't. GetThreadContext() documentation says it is not=
 guaranteed to return a valid context for running threads. What I think t=
hey mean is that the context will not remain valid after GetThreadContext=
() if the thread is running. As long as the existing stack at the time of=
 the GetThreadContext() does not get modified while trying to walk it I d=
on't think there would be a problem.

I've updated the patch to fix a mingw compile problem and fix some code s=
tyle/formatting.


----------------------------------------
http://redmine.ruby-lang.org/issues/show/3875

----------------------------------------
http://redmine.ruby-lang.org

Attachments (1)

---
 include/ruby/win32.h |    3 ++
 vm_dump.c            |    2 +
 win32/win32.c        |   96 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/include/ruby/win32.h b/include/ruby/win32.h
index 7b6bded..db646b2 100644
--- a/include/ruby/win32.h
+++ b/include/ruby/win32.h
@@ -672,6 +672,9 @@ in asynchronous_func_t.
 typedef uintptr_t (*asynchronous_func_t)(uintptr_t self, int argc, uintptr_t* argv);
 uintptr_t rb_w32_asynchronize(asynchronous_func_t func, uintptr_t self, int argc, uintptr_t* argv, uintptr_t intrval);
 
+/* backtrace */
+void rb_w32_backtrace();
+
 #if defined __GNUC__ && __GNUC__ >= 4
 #pragma GCC visibility pop
 #endif
diff --git a/vm_dump.c b/vm_dump.c
index f245ccc..c0199b1 100644
--- a/vm_dump.c
+++ b/vm_dump.c
@@ -616,5 +616,7 @@ rb_vm_bugreport(void)
 	}
 	fprintf(stderr, "\n");
     }
+#elif _WIN32
+    rb_w32_backtrace();
 #endif
 }
diff --git a/win32/win32.c b/win32/win32.c
index 46cdafa..8346b8f 100644
--- a/win32/win32.c
+++ b/win32/win32.c
@@ -36,6 +36,9 @@
 #ifdef __MINGW32__
 #include <mswsock.h>
 #endif
+#if _MSC_VER && _M_IX86
+#include <DbgHelp.h>
+#endif
 #include "ruby/win32.h"
 #include "win32/dir.h"
 #define isdirsep(x) ((x) == '/' || (x) == '\\')
@@ -5694,3 +5697,96 @@ signbit(double x)
     return *ip < 0;
 }
 #endif
+
+#if _MSC_VER && _M_IX86
+static struct DumpArgs {
+    DWORD thread_id;
+    HANDLE event;
+};
+
+static void
+dump_thread(void *arg)
+{
+    struct DumpArgs* dump_args = (struct DumpArgs*)arg;
+    HANDLE process = GetCurrentProcess();
+    HANDLE thread = OpenThread(THREAD_ALL_ACCESS, 0, dump_args->thread_id);
+    STACKFRAME64 stackFrame;
+    CONTEXT context;
+    DWORD64 dwDisplacement;
+    DWORD64 dwAddress;
+    char buffer[sizeof(SYMBOL_INFO) + MAX_SYM_NAME * sizeof(TCHAR)];
+    PSYMBOL_INFO pSymbol = (PSYMBOL_INFO)buffer;
+    IMAGEHLP_LINE64 line;
+    DWORD dwLineDisplacement;
+
+    SymSetOptions(SYMOPT_UNDNAME | SYMOPT_DEFERRED_LOADS | SYMOPT_DEBUG | 
+                  SYMOPT_LOAD_LINES);
+
+    if (!SymInitialize(process, NULL, TRUE)) abort();
+
+    memset(&context, 0, sizeof(CONTEXT));
+    context.ContextFlags = CONTEXT_FULL;
+    if (!GetThreadContext(thread, &context)) abort();
+
+    memset(&stackFrame, 0, sizeof(STACKFRAME64));
+    stackFrame.AddrPC.Mode = AddrModeFlat;
+    stackFrame.AddrPC.Offset = context.Eip;
+
+    stackFrame.AddrFrame.Mode = AddrModeFlat;
+    stackFrame.AddrFrame.Offset = context.Ebp;
+
+    stackFrame.AddrStack.Mode = AddrModeFlat;
+    stackFrame.AddrStack.Offset = context.Esp;
+
+    fprintf(stderr, "-- C level backtrace information "
+            "-------------------------------------------\n");
+
+    while (StackWalk64(IMAGE_FILE_MACHINE_I386, process, thread, &stackFrame,
+                       (PVOID)&context, NULL, SymFunctionTableAccess64, 
+                       SymGetModuleBase64, NULL)) {
+        dwDisplacement = 0;
+        dwAddress = stackFrame.AddrPC.Offset;
+
+	memset(buffer, 0, sizeof(buffer));
+	pSymbol->SizeOfStruct = sizeof(SYMBOL_INFO);
+	pSymbol->MaxNameLen = MAX_SYM_NAME;
+
+	if (SymFromAddr(process, dwAddress, &dwDisplacement, pSymbol)) {
+            fprintf(stderr, "(%s)", pSymbol->Name);
+	}
+
+	memset(&line, 0, sizeof(IMAGEHLP_LINE64));
+	line.SizeOfStruct = sizeof(IMAGEHLP_LINE64);
+
+	if (SymGetLineFromAddr64(process, dwAddress, &dwLineDisplacement, 
+                                 &line)) {
+            fprintf(stderr, "(%s:%lu)", line.FileName, line.LineNumber);
+	}
+
+        fprintf(stderr, " [0x%08I64x]\n", dwAddress);
+    }
+    fprintf(stderr, "\n");
+
+    if (!CloseHandle(thread)) abort();
+    if (!SymCleanup(process)) abort();
+    if (!SetEvent(dump_args->event)) abort();
+}
+
+void 
+rb_w32_backtrace() {
+    struct DumpArgs dump_args;
+    dump_args.thread_id = GetCurrentThreadId();
+    dump_args.event = CreateEvent(NULL, TRUE, FALSE, NULL);
+    if(!dump_args.event) abort();
+    _beginthread(dump_thread,0,&dump_args);
+
+    if (WaitForSingleObject(dump_args.event, INFINITE) != WAIT_OBJECT_0) 
+        abort();
+}
+#else
+void 
+rb_w32_backtrace() {
+}
+#endif
+
+
-- 

In This Thread