How to troubleshoot crashes?

[Jarmo Pertman]

Hi!

I'm using TCS builds of Ruby, but for some reason started getting crashes for one specific project. I tried to minimize the code involved and solved one problem by updating a rspec gem (doesn't make sense actually, but it worked - i even tried uninstalling that newer version and crashes were back), but i'm still getting random crashes. Since i don't feel myself at home debugging these kinds of things then i'm hoping that someone from here can help me with this.

Here is the "minimal" code needed to reproduce the crashes on my 64bit win7:

require "rspec"

require "win32ole"

require "sinatra"

class MyApp < Sinatra::Base

  set :server, :webrick

end

describe "crash" do

  before do

    @thread = Thread.new {MyApp.run!}

  end

  

  it "it will crash - always" do  

ie = WIN32OLE.new('InternetExplorer.Application')

ie.navigate "about:blank"

ie.visible = true

puts ie.document.location

  end

  

  after do

    @thread.join

  end

  

end

1. RSpec has to be used, it won't crash without it

2. Sinatra app thread has to be started at "before" or "let" block - it won't crash if i move it to the start of "it" block

3. Thread has to be joined in "after" block - it won't crash if moved to the end of "it" block

4. ie.document.location code has to be called - it won't crash otherwise

As you can see - here are some really strange conditions for the crash to happen.

Versions:

tcs-ruby 1.9.3p231 (2012-05-25, TCS patched 2012-05-27) [i386-mingw32]

sinatra (1.3.2)

rspec (2.9.0)

rspec-core (2.9.0)

rspec-expectations (2.9.0)

rspec-mocks (2.9.0)

If i upgrade rspec to 2.11.0 then the code above does NOT create a crash anymore, but more complex code still causes crashes. I suspect it has something to do with the win32ole, maybe some other code with other conditions, really hard to find out since as mentioned above then crashes after rspec upgrade seem to happen at random times so i can't put a breakpoint into ruby code yet.

Crashes also happen with tcs-ruby 1.9.3p196 (2012-04-21, TCS patched 2012-04-21). The code above won't crash official RubyInstaller 1.9.3p194, but i see random crashes with that too. 

At first i have some really general questions - how to get more meaningful information about crashes compared to Windows event viewer where i can just see that ruby.exe has crashed?

Can i find out somehow which line of Ruby code creates the situation, which causes a crash?

Any other helpful tips which might help me regarding this kind of errors?

[Jarmo Pertman]

I investigated further and managed to get one segfault too, maybe they're related. Segfault output can be seen here  https://gist.github.com/3193652#file_gistfile1.txt . Maybe it helps.

Line 317 which the segfault refers to, can be seen here:

https://github.com/jarmo/RAutomation/blob/master/lib/rautomation/adapter/win_32/functions.rb#L317 

I haven't changed that code for years now so that can't be the exact culprit. I have however upgraded ffi today to 1.1.1. Just downgraded it back to 1.0.11 and haven't seen segfaults just yet. Still testing before switching back to 1.1.1 to see if i can reproduce it and then will probably open up an issue at ffi.

In that light it seems to me that i'm having more than one issue happening together.

Jarmo

[Luis Lavena]

For the record: win32ole replaces thread initialize, so mixing
win32ole with threads might present some problem.

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[Jarmo Pertman]

Hmm, that might seem the problem indeed, because i changed my code to not use thread, but run server in a sub process instead and crashing stopped. But how to investigate it further so this problem could be fixed in Ruby?

Just FYI, i've opened up an issue regarding ffi at https://github.com/ffi/ffi/issues/213 

Jarmo

[Luis Lavena]

On Sat, Jul 28, 2012 at 12:39 PM, Jarmo Pertman <jar...@gmail.com> wrote:
> Hmm, that might seem the problem indeed, because i changed my code to not
> use thread, but run server in a sub process instead and crashing stopped.
> But how to investigate it further so this problem could be fixed in Ruby?
>

win32ole needs to replace thread initialize so coinitialize works.

I don't think Ruby implementation of win32ole plays nice with native
threads, so I would recommend find a way around that.

> Just FYI, i've opened up an issue regarding ffi at
> https://github.com/ffi/ffi/issues/213
>

I just requested you provide a minimized/synthetized test case that
expose the crash.

[Jarmo Pertman]

On Saturday, July 28, 2012 6:41:55 PM UTC+3, Luis Lavena wrote:

On Sat, Jul 28, 2012 at 12:39 PM, Jarmo Pertman <jar...@gmail.com> wrote:
> Hmm, that might seem the problem indeed, because i changed my code to not
> use thread, but run server in a sub process instead and crashing stopped.
> But how to investigate it further so this problem could be fixed in Ruby?
>

win32ole needs to replace thread initialize so coinitialize works.

I don't think Ruby implementation of win32ole plays nice with native
threads, so I would recommend find a way around that.

So what you're saying is that if Win32Ole is loaded then threads should be avoided?

 

> Just FYI, i've opened up an issue regarding ffi at
> https://github.com/ffi/ffi/issues/213
>

I just requested you provide a minimized/synthetized test case that
expose the crash.

noticed and done :) 

[Luis Lavena]

On Sat, Jul 28, 2012 at 12:52 PM, Jarmo Pertman <jar...@gmail.com> wrote:
> On Saturday, July 28, 2012 6:41:55 PM UTC+3, Luis Lavena wrote:
>>
>> I don't think Ruby implementation of win32ole plays nice with native
>> threads, so I would recommend find a way around that.
>
> So what you're saying is that if Win32Ole is loaded then threads should be
> avoided?
>

Once win32ole is loaded, thread is not the same, even a test is
excluded because of that:

https://github.com/ruby/ruby/blob/trunk/test/ruby/test_thread.rb#L607

If Thread is no longer Thread after win32ole has been loaded, perhaps
is fair to say that something might go wrong with that combination.

If using win32ole without thread works, or using thread without
win32ole works then the issue is in the combo.

If you figure out a contrived/minimal test that can expose the bug
(not depending on gems), perhaps we can work towards fixing it.

>
>> > Just FYI, i've opened up an issue regarding ffi at
>> > https://github.com/ffi/ffi/issues/213
>> >
>>
>> I just requested you provide a minimized/synthetized test case that
>> expose the crash.
>
> noticed and done :)

Going to continue the FFI crash conversation on the ticket.