Bug #9357: TracePoint's c_return traces return from call to 'trace'

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: 2.1.0

[andhapp (Anuj Dutta)]

=begin
Hello,

In TracePoint, trace on 'c_call' doesn't trace the call made to 'trace' method, where as trace on 'c_return' does, is this expected behaviour?

Here's the code I used to reproduce it:

=== Code (c_return)
class Car
def self.start
print "Started..."
end
end

TracePoint.trace(:c_return) do |tp|
  puts "'#{tp.event}' event occurred in #{tp.defined_class}##{tp.method_id}"
end

Car.start

=== Env

Ruby 2.1.0

=== Actual output

'c_return' event occurred in #<Class:TracePoint>#trace
Started...'c_return' event occurred in IO#write
'c_return' event occurred in Kernel#print

=== Expected output

Started...'c_return' event occurred in IO#write
'c_return' event occurred in Kernel#print

=== Code on eval.in

Here's the link to code on eval.in:

https://eval.in/85264

Thanks.

[deivid (David Rodríguez)]

I think this is expected because tracing is enabled inside the trace method, not after, nor before.

Does that behaviour cause any trouble?

It doesn't cause any issues, however that doesn't seem to happen when one
traces on c_call. Here's the code:

https://eval.in/85228

Thanks.

On 3 January 2014 11:51, deivid (David Rodríguez) <
[e-mail]> wrote:

Issue #9357 has been updated by deivid (David Rodríguez).

I think this is expected because tracing is enabled inside the trace
method, not after, nor before.

Does that behaviour cause any trouble?

Bug #9357: TracePoint's c_return traces return from call to 'trace'
https://bugs.ruby-lang.org/issues/9357#change-44061

Author: andhapp (Anuj Dutta)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: 2.1.0
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN

=begin
Hello,

In TracePoint, trace on 'c_call' doesn't trace the call made to 'trace'
method, where as trace on 'c_return' does, is this expected behaviour?

Here's the code I used to reproduce it:

=== Code (c_return)
class Car
def self.start
print "Started..."
end
end

TracePoint.trace(:c_return) do |tp|
  puts "'#{tp.event}' event occurred in

#{tp.defined_class}##{tp.method_id}"
end

Car.start

=== Env

Ruby 2.1.0

=== Actual output

'c_return' event occurred in #<Class:TracePoint>#trace
Started...'c_return' event occurred in IO#write
'c_return' event occurred in Kernel#print

=== Expected output

Started...'c_return' event occurred in IO#write
'c_return' event occurred in Kernel#print

=== Code on eval.in

Here's the link to code on eval.in:

https://eval.in/85264

Thanks.

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

--
Anuj DUTTA

[deivid (David Rodríguez)]

Yes, because tracing is enabled after the 'c_call' and before the 'c_return' event.

Makes sense.

Thanks.

Will close this now.

On 3 January 2014 14:42, deivid (David Rodríguez) <
[e-mail]> wrote:

Issue #9357 has been updated by deivid (David Rodríguez).

Yes, because tracing is enabled after the 'c_call' and before the
'c_return' event.

Bug #9357: TracePoint's c_return traces return from call to 'trace'
https://bugs.ruby-lang.org/issues/9357#change-44067

Author: andhapp (Anuj Dutta)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: 2.1.0
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN

=begin
Hello,

In TracePoint, trace on 'c_call' doesn't trace the call made to 'trace'
method, where as trace on 'c_return' does, is this expected behaviour?

Here's the code I used to reproduce it:

=== Code (c_return)
class Car
def self.start
print "Started..."
end
end

TracePoint.trace(:c_return) do |tp|
  puts "'#{tp.event}' event occurred in

#{tp.defined_class}##{tp.method_id}"
end

Car.start

=== Env

Ruby 2.1.0

=== Actual output

'c_return' event occurred in #<Class:TracePoint>#trace
Started...'c_return' event occurred in IO#write
'c_return' event occurred in Kernel#print

=== Expected output

Started...'c_return' event occurred in IO#write
'c_return' event occurred in Kernel#print

=== Code on eval.in

Here's the link to code on eval.in:

https://eval.in/85264

Thanks.

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

--
Anuj DUTTA

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed
• Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN)