Bug #18343


empty hash passed to Array#pack causes Segmentation fault (2.6)

Added by Ethan (Ethan -) about 1 year ago. Updated about 1 year ago.

Target version:
ruby -v:
ruby 2.6.8p205 (2021-07-07 revision 67951) [x86_64-linux]


passing an empty hash to Array#pack segfaults from ruby 2.4 to ruby 2.6 on ubuntu, macos, and windows.

[0].pack('c', {})

pack takes a keyword argument, and handles unknown keywords, but the empty hash segfaults.

here is the error trace in a github workflow running only the above expression: (other ruby versions and OSes are part of the same run)

Updated by xtkoba (Tee KOBAYASHI) about 1 year ago

Proposed patch:

--- ruby-2.6.8/pack.c.orig
+++ ruby-2.6.8/pack.c
@@ -330,7 +330,7 @@ pack_pack(int argc, VALUE *argv, VALUE a
 	if (buffer != Qundef && !RB_TYPE_P(buffer, T_STRING))
 	    rb_raise(rb_eTypeError, "buffer must be String, not %s", rb_obj_classname(buffer));
-    if (buffer)
+    if (buffer && buffer != Qundef)
 	res = buffer;
 	res = rb_str_buf_new(0);

Updated by jeremyevans0 (Jeremy Evans) about 1 year ago

  • Status changed from Open to Closed
  • Backport changed from 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN to 2.6: REQUIRED, 2.7: DONTNEED, 3.0: DONTNEED

This is definitely a bug in ruby 2.4 - 2.6, but ruby 2.4 and 2.5 are end of life, and ruby 2.6 is in security maintenance mode. I don't think this is a security issue, but just in case, I'll mark this for backporting for ruby 2.6. It is up to the ruby 2.6 branch maintainer whether it is actually backported.

Updated by Ethan (Ethan -) about 1 year ago

agreed that it's not a security issue, and questionable whether it's worth fixing for a version near EOL. I only encountered this during an early/flawed attempt at generic argument delegation to some Array methods, but that has been rewritten and this issue does not affect me. a segfault in a supported Ruby still seemed worth reporting, but not fine to close.

Updated by jeremyevans0 (Jeremy Evans) about 1 year ago

It's fixed in the master branch of Ruby, that's why it is closed. It's marked for backporting, because that is how backport requests are handled in Redmine. Doing this includes the issue in the list of backportable issues for 2.6 (

Updated by Ethan (Ethan -) about 1 year ago

oops, in writing that last sentence a "not" slipped by me and I said the opposite of what I meant to say. I meant to say "seemed worth reporting, but fine to close." did not mean to complain about the closing, brainfart.


Also available in: Atom PDF