Project

General

Profile

Actions

Bug #13788

closed

Updated by nobu (Nobuyoshi Nakada) almost 8 years ago

  • Status changed from Open to Feedback

To initialize a library properly is a responsibility of programs which use it, isn't it?

Updated by branan (Branan Riley) almost 8 years ago

It appears from the comment on ruby_sysinit that programs embedding ruby should NOT be calling it under normal usage:

/*! Initializes the process for ruby(1).
 *
 * This function assumes this process is ruby(1) and it has just started.
 * Usually programs that embeds CRuby interpreter should not call this function,
 * and should do their own initialization.
 */

Further, looking at the logic in dladdr_path, it appears to boil down to:

  • if we are a statically-linked ruby executable, lookup our libpath from /proc/self/exe
  • else, lookup our libpath from the Dl_info struct

If my interpretation of that logic is correct, it would not make sense for origarg to be set when embedding the ruby interpreter. We'd expect to fall through to the second case: looking up the libpath from where the ruby shared library is located.

All that aside, since there is a reasonable behavior if origarg.argv is NULL (using the Dl_info struct), I would expect the function to handle that case and allow the program to continue, instead of segfaulting.

Updated by nobu (Nobuyoshi Nakada) almost 8 years ago

  • Status changed from Feedback to Closed

Applied in changeset trunk|r59549.


ruby.c: origarg

  • ruby.c (dladdr_path, ruby_set_argv): add guards for origarg.
    [ruby-core:82272] [Bug ]

  • ruby.c (proc_options, process_options, ruby_process_options):
    set origarg if not set yet.

  • ruby.c (process_options): prefer argv in the argument to origarg
    as program name.

  • ruby.c (ruby_sysinit): set origarg only if argc and argv seem
    valid.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0