[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Ruby C extension crash: how to create a stack trace?

igor.sarzisartori@gmail.com

4/6/2007 6:17:00 PM

Hi,

I am using ruby to test and develop my legacy C code. I packed it
inside a ruby extension as dll under windows. I am using visual
studio 6 to debug my extension.
The process works very well, but when I make a mistake in my C code
ruby abort without stack trace and it is difficult for me to find the
reason.
Here a trivial example. I have exported the buggy function
foo_thread_handler to ruby:

void foo_thread_handler()
{
while(1)
{
// a thread task
mystruct* pCrash = 0; // null pointer usage
pCrash->len = 555; // crash with 0xC0000005: Access
Violation.
do_realstuff(); // do real stuff
// call a function inside ruby to get back to the scheduler
rb_something()
}
}

and in ruby:
require 'myextension'
Thread.new {
begin
Myextension::foo_thread_handler()
rescue Exception => detail
puts " c extension code error"
end
}

def rb_something
puts "I am alive"
end

How can avoid ruby to silent abort when pCrash->len = 555; is
executed?
I am interested on stack trace, because it is not created, or an
assert to identify the code that make a crash.
Usually such exceptions are handled inside visual studio, but if I run
ruby inside it, in order to debug my extension, this doesn't happens.
I think to rebuild ruby and modify error.c to avoid abort() call
inside rb_bug(), but I am looking for a better solution.

Regards,
Igor
6 Answers

igor.sarzisartori@gmail.com

4/9/2007 6:32:00 PM

0

I have tried with :

trap("SEGV"){"my seg fault handler";exit}
Myextension::foo_thread_handler()

Trap seam to intercept the segmentation fault, but there is an
infinite recursion of the trap. The dos shell is blocked. If a run the
script inside visual studio, it is also blocked and I have to kill it
with task manager.
I use ruby under windows:
C:\Documents and Settings\igor>ruby -v
ruby 1.8.4 (2006-04-14) [i386-mswin32]

Ryan Davis

4/9/2007 9:45:00 PM

0


On Apr 6, 2007, at 11:20 , barabba wrote:

> Hi,
>
> I am using ruby to test and develop my legacy C code. I packed it
> inside a ruby extension as dll under windows. I am using visual
> studio 6 to debug my extension.
> The process works very well, but when I make a mistake in my C code
> ruby abort without stack trace and it is difficult for me to find the
> reason.

I haven't done any MS development in over a decade (happily), so
maybe I'm just missing something. This is how I get a BT on OSX/
FreeBSD when I'm debugging my extensions:

% gdb ruby
> r my_script.rb my_args
.... go boom
> bt
... backtrace with hopefully useful information

Can you not do that from the MS debugger???

igor.sarzisartori@gmail.com

4/10/2007 7:22:00 PM

0

On Apr 9, 11:44 pm, Ryan Davis <ryand-r...@zenspider.com> wrote:
> On Apr 6, 2007, at 11:20 , barabba wrote:
>
> > Hi,
>
> > I am using ruby to test and develop my legacy C code. I packed it
> > inside a ruby extension as dll under windows. I am using visual
> > studio 6 to debug my extension.
> > The process works very well, but when I make a mistake in my C code
> > ruby abort without stack trace and it is difficult for me to find the
> > reason.
>
> I haven't done any MS development in over a decade (happily), so
> maybe I'm just missing something. This is how I get a BT on OSX/
> FreeBSD when I'm debugging my extensions:
>
> % gdb ruby
> > r my_script.rb my_args
> ... go boom
> > bt
> .. backtrace with hopefully useful information
>
> Can you not do that from the MS debugger???

Yes it is fast the same. MSVC start and run ruby using my_script.rb as
argument. The problem is the "backtrace", it is only one line, because
ruby don't crash, just exit.
I have solved my problem directly in the C part using Structured
Exception Handling(SEH) of win32.
Now my extension looks like:
void foo_thread_handler()
{
__try{
while(1)
{
// a thread task
mystruct* pCrash = 0; // null pointer usage
pCrash->len = 555; // BOOM
do_realstuff(); // do real stuff
// call a function inside ruby to get back to the scheduler
rb_something()
}
}
__except ( EXCEPTION_EXECUTE_HANDLER )
{
printf("Boom recognized\n");
}

}

This solution works only under MSVC compiler, but it is ok for me.

It is still not clear why
trap("SEGV"){"my seg fault handler";exit}
doesn't work on my system. It seam that the exception is caught, but
the C code is recalled at the same place where the error is generated
causing an infinite loop (may be an EXCEPTION_CONTINUE_EXECUTION is
used in the trap handler?).

Paul Brannan

4/10/2007 8:15:00 PM

0

On Wed, Apr 11, 2007 at 04:25:11AM +0900, barabba wrote:
> Yes it is fast the same. MSVC start and run ruby using my_script.rb as
> argument. The problem is the "backtrace", it is only one line, because
> ruby don't crash, just exit.

Gdb stops when the application gets a signal, rather than waiting for
the application to terminate.

> It is still not clear why
> trap("SEGV"){"my seg fault handler";exit}
> doesn't work on my system. It seam that the exception is caught, but
> the C code is recalled at the same place where the error is generated
> causing an infinite loop (may be an EXCEPTION_CONTINUE_EXECUTION is
> used in the trap handler?).

If you segfault, you have already entered into the world of undefined
behavior. Anything your application does after that point is
unpredictable.

(For that reason, in most applications it's better to let the
application crash than to continue running in a bad state).

Do you get a stack trace if you place a breakpoint in sighandler() (in
signal.c)?

Paul

igor.sarzisartori@gmail.com

4/12/2007 12:06:00 AM

0

On Apr 10, 10:15 pm, Paul Brannan <pbran...@atdesk.com> wrote:
> On Wed, Apr 11, 2007 at 04:25:11AM +0900, barabba wrote:
> > Yes it is fast the same. MSVC start and run ruby using my_script.rb as
> > argument. The problem is the "backtrace", it is only one line, because
> > ruby don't crash, just exit.
>
> Gdb stops when the application gets a signal, rather than waiting for
> the application to terminate.
>
> > It is still not clear why
> > trap("SEGV"){"my seg fault handler";exit}
> > doesn't work on my system. It seam that the exception is caught, but
> > the C code is recalled at the same place where the error is generated
> > causing an infinite loop (may be an EXCEPTION_CONTINUE_EXECUTION is
> > used in the trap handler?).
>
> If you segfault, you have already entered into the world of undefined
> behavior. Anything your application does after that point is
> unpredictable.
>
> (For that reason, in most applications it's better to let the
> application crash than to continue running in a bad state).
>
> Do you get a stack trace if you place a breakpoint in sighandler() (in
> signal.c)?
>
> Paul

I have built a debug version of ruby 1.8.6 under windows with msvc6.
A breakpoint in sighandler() is not reached.
I have set also a breakpoint in sigsegv(sig)

This is the stack trace when the extension crash and reach the
breakpoint:
sigsegv(int 11) line 622
MSVCRT! 77c32efa()
RUBY! mainCRTStartup + 257 bytes
KERNEL32! 7c816d4f()

This say nothing where my extension crash, but maybe it is possible to
get more information using win32 GetExceptionInformation(). Not really
comfortable. May be it is better the possibility to turn off SEH
inside ruby and leave this to visual studio. But I haven't found in
ruby source how SEH are turned on.

JamesHutchinson

12/3/2013 1:11:00 PM

0



"deep" wrote in message news:flup99hlbodaqtsegr310gc3ofslcq0tpc@4ax.com...

On Mon, 02 Dec 2013 14:38:20 -0600, RD Sandman
<rdsandman[remove]comcast.net> wrote:

>Not really in a fee simple real estate system like we have here, the
>property is freely owned and can be freely sold or transferred. The only
>obligation to the state is a property tax based on its value. The state
>doesn't own the land or property, it just has a power to tax which it
>does on income, sales and property depending on the state.
>
>
The state also has the power to condemn and seize any property they
want.

######
When they see yours, you're DOOMED when they see your "pantry!"