Project

General

Profile

Bug #4630

PROCDEBUG to non-zero values causes segmentation faults in check_env in trunk

Added by ehuard (Elise Huard) over 6 years ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Target version:
[ruby-core:35940]

Description

PROCDEBUG is meant to show debugging output from the vm.
However, when it's activated in vm.c
#define PROCDEBUG 1
The make process fails in segmentation faults.

I've narrowed it down to the following variables displayed in check_env: env->block.dfp[3] and env->block.dfp[4]
Commenting them out like so makes the segfaults disappear.

  static int
  check_env(rb_env_t * const env)
  {
      printf("---\n");
      printf("envptr: %p\n", (void *)&env->block.dfp[0]);
      printf("orphan: %p\n", (void *)env->block.dfp[1]);
      printf("inheap: %p\n", (void *)env->block.dfp[2]);
      /* printf("envval: %10p ", (void *)env->block.dfp[3]);
      dp(env->block.dfp[3]);
      printf("penvv : %10p ", (void *)env->block.dfp[4]);
       dp(env->block.dfp[4]); */
      printf("lfp:    %10p\n", (void *)env->block.lfp);
      printf("dfp:    %10p\n", (void *)env->block.dfp);
    /*  if (env->block.dfp[4]) {
          printf(">>\n");
          check_env_value(env->block.dfp[4]);
          printf("<<\n");
      } */
      return 1;
  }

However, I'm not clued up enough on the inner workings of the VM to say why or how that should be fixed intelligently.

History

#1 [ruby-core:36933] Updated by ko1 (Koichi Sasada) over 6 years ago

  • ruby -v changed from 1.9.3dev to -

Hi,

(2011/04/29 4:52), Elise Huard wrote:

PROCDEBUG is meant to show debugging output from the vm.
However, when it's activated in vm.c
#define PROCDEBUG 1
The make process fails in segmentation faults.

Oops. I don't touch it on long time (because there is no bug which
requires this debug option). So maybe this check_env() doesn't catch up
Proc data structure.

--
// SASADA Koichi at atdot dot net

#2 [ruby-core:37006] Updated by ko1 (Koichi Sasada) over 6 years ago

  • Category set to core
  • Status changed from Open to Assigned
  • Assignee set to ko1 (Koichi Sasada)
  • Priority changed from Normal to 3

#3 [ruby-core:37497] Updated by nahi (Hiroshi Nakamura) over 6 years ago

  • Target version set to 2.0.0

#4 [ruby-core:50125] Updated by ko1 (Koichi Sasada) almost 5 years ago

  • Target version changed from 2.0.0 to next minor

#5 [ruby-core:79349] Updated by ko1 (Koichi Sasada) 9 months ago

  • Status changed from Assigned to Closed
  • Description updated (diff)

Now, we don't see this issue.

Also available in: Atom PDF