From: "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "nobu (Nobuyoshi Nakada)" <ruby-core@ml.ruby-lang.org>
Subject: [ruby-core:113501] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
Date: Wed, 17 May 2023 02:03:48 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-103096.20230517020348.7176@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-18743.20220419144209.7176@ruby-lang.org
Issue #18743 has been updated by nobu (Nobuyoshi Nakada).
Seems find to me.
One thing I concerned, `stop_exc` will be re-created every times, and no way to know where it was first used up.
How about chaining by `cause`?
```diff
diff --git a/enumerator.c b/enumerator.c
index b33c1713718..1cc8f9108cf 100644
--- a/enumerator.c
+++ b/enumerator.c
@@ -30,6 +30,9 @@
#include "internal/rational.h"
#include "ruby/ruby.h"
+extern ID ruby_static_id_cause;
+#define id_cause ruby_static_id_cause
+
/*
* Document-class: Enumerator
*
@@ -787,8 +790,16 @@ get_next_values(VALUE obj, struct enumerator *e)
{
VALUE curr, vs;
- if (e->stop_exc)
- rb_exc_raise(e->stop_exc);
+ if (e->stop_exc) {
+ VALUE exc = e->stop_exc;
+ VALUE result = rb_attr_get(exc, id_result);
+ VALUE mesg = rb_attr_get(exc, idMesg);
+ if (!NIL_P(mesg)) mesg = rb_str_dup(mesg);
+ VALUE stop_exc = rb_exc_new_str(rb_eStopIteration, mesg);
+ rb_ivar_set(stop_exc, id_result, result);
+ rb_ivar_set(stop_exc, id_cause, exc);
+ rb_exc_raise(stop_exc);
+ }
curr = rb_fiber_current();
```
In the test, save `$!` at the first `rescue` then `assert_same(cause, exc.cause)`.
----------------------------------------
Bug #18743: Enumerator#next / peek re-use each others stacktraces
https://bugs.ruby-lang.org/issues/18743#change-103096
* Author: sos4nt (Stefan Schüßler)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
I encountered an odd behavior.
If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa)
```ruby
# enum.rb # 1
# 2
enum = [].each # 3
enum.peek rescue nil # 4
enum.next # 5
```
it will show the stacktrace from the rescued `peek` call:
```
$ ruby enum.rb
enum.rb:4:in `peek': iteration reached an end (StopIteration)
from enum.rb:4:in `<main>'
```
Whereas the error should refer to `next` on line number 5.
The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls:
```ruby
# enum.rb # 1
# 2
enum = [].each # 3
enum.peek rescue nil # 4
enum.next rescue nil # 5
enum.peek rescue nil # 6
puts "line #{__LINE__}" # 7
enum.next # 8
```
The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location:
```
$ ruby enum.rb
line 7
enum.rb:4:in `peek': iteration reached an end (StopIteration)
from enum.rb:4:in `<main>'
```
This is very confusing when debugging code.
---Files--------------------------------
01-Recreate-stacktrace-enumerator.patch (1.29 KB)
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/
next prev parent reply other threads:[~2023-05-17 2:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 14:42 [ruby-core:108294] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces sos4nt
2022-07-29 13:54 ` [ruby-core:109366] " marcper (Marcelo Pereira)
2022-09-04 14:50 ` [ruby-core:109841] " marcper (Marcelo Pereira)
2022-10-06 8:42 ` [ruby-core:110205] " marcper (Marcelo Pereira)
2022-10-23 13:09 ` [ruby-core:110491] " marcper (Marcelo Pereira)
2022-11-09 8:17 ` [ruby-core:110666] " marcper (Marcelo Pereira)
2022-12-29 8:56 ` [ruby-core:111498] " marcper (Marcelo Pereira) via ruby-core
2023-03-03 8:58 ` [ruby-core:112675] " marcper (Marcelo Pereira) via ruby-core
2023-03-09 6:26 ` [ruby-core:112763] " ko1 (Koichi Sasada) via ruby-core
2023-03-10 3:35 ` [ruby-core:112820] " matz (Yukihiro Matsumoto) via ruby-core
2023-03-18 14:28 ` [ruby-core:112941] " marcper (Marcelo Pereira) via ruby-core
2023-04-01 10:10 ` [ruby-core:113069] " marcper (Marcelo Pereira) via ruby-core
2023-05-16 13:03 ` [ruby-core:113497] " marcper (Marcelo Pereira) via ruby-core
2023-05-17 2:03 ` nobu (Nobuyoshi Nakada) via ruby-core [this message]
2023-05-19 14:55 ` [ruby-core:113531] " marcper (Marcelo Pereira) via ruby-core
2023-06-07 6:48 ` [ruby-core:113786] " nobu (Nobuyoshi Nakada) via ruby-core
2023-06-26 19:41 ` [ruby-core:114024] " marcper (Marcelo Pereira) via ruby-core
2023-07-14 12:09 ` [ruby-core:114185] " marcper (Marcelo Pereira) via ruby-core
2023-10-29 11:38 ` [ruby-core:115195] " marcper (Marcelo Pereira) via ruby-core
2024-02-25 9:29 ` [ruby-core:116935] " nagachika (Tomoyuki Chikanaga) via ruby-core
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-103096.20230517020348.7176@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
--cc=ruby-core@ml.ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).