【问题标题】:Segmentation fault with ucontext makecontext on OS X 10.10OS X 10.10 上 ucontext makecontext 的分段错误
【发布时间】:2015-09-21 20:20:00
【问题描述】:
#include <stdio.h>
#include <stdlib.h>
#define _XOPEN_SOURCE 600
#include <ucontext.h>

/* Tests creation.
   Should print "Hello World!" */

typedef struct thread_t{
  ucontext_t thread_context;
}thread_t;

void *thr1(void *in) {
  printf("Hello World!\n");
  fflush(stdout);
  return NULL;
}

void *thr2(void *in) {
  printf("goodbye World!\n");
  fflush(stdout);
  return NULL;
}

int main() {
  thread_t t1;
  thread_t t2;

  thread_create( &t1, thr1, NULL);
  // if you comment out the following line, the program will run like a charm. 
  thread_create( &t2, thr2, NULL);
  setcontext(&t1.thread_context);

  return EXIT_SUCCESS;
}

void thread_routine(void *(*start_routine)(void *), void *arg)
{
  start_routine(arg);
  printf("gtthread routine finished\n");
}

int thread_create(thread_t *thread,
        void *(*start_routine)(void *),
        void *arg){
  if (getcontext(&(thread->thread_context)) == -1)
  {
    perror("getcontext");
  }

  thread->thread_context.uc_stack.ss_sp = (char*) malloc(SIGSTKSZ);
  thread->thread_context.uc_stack.ss_size = SIGSTKSZ;
  thread->thread_context.uc_link = NULL;

  makecontext(&(thread->thread_context), thread_routine, 2, (void *)start_routine, arg);
}

我使用 gcc 在 OS X 10.10 中运行我的代码。我正在尝试实现一个用户上下文库。

如果我注释掉thread_create( &amp;t2, thr2, NULL);,代码将产生预期的效果。我不知道为什么与t2 相关的行会导致t1 的分段错误。

作者注

在切换到 Ubuntu 后,我很高兴地致力于实现用户上下文库。一切正常。不再有分段错误。正如预期的那样,它在 OS X 10.10 上崩溃了。

我的猜测是,由于编译器警告说,自 10.6 起 OS X 已弃用 makecontext()、swapcontext() 等,所以我不应该期望它会起作用。

【问题讨论】:

  • 这个程序遇到了很多未定义的行为。即:各种函数的返回值不正确,return-statements 丢失,参数类型不正确。
  • 我已经尝试在 Ubuntu 12 LTS 中编译我的代码,它可以工作。这令人困惑。我怎样才能让它在 OS X 上运行?

标签: c linux segmentation-fault pthreads ucontext


【解决方案1】:

您的程序有一些缺陷,其中一些会导致它产生未定义的行为。未定义的行为可能会完全按照您的预期表现出来,但如果它恰好在某个特定环境中这样做了一次,那并不能提供任何理由期望它会再次这样做 - 不是在那个环境中,并且当然不是在不同的环境中。

以下是我注意到的更严重的问题:

  • thread_routine() 没有正确的返回类型或上下文启动函数的参数类型。上下文启动函数预计返回void(即什么都没有)而不是void *,这是完全不同的。此外,传递给它的实际参数(如果有的话)都将是int 类型。因此,当您的程序作为setcontext() 的结果调用此函数时,会导致未定义的行为。在函数指针和对象指针的大小都与int 相同的机器上,您可能会侥幸逃脱,但在其他机器上,程序可能会严重崩溃。这可能是您观察到的段错误的原因。

  • thread_create() 中,您将thread-&gt;thread_context.uc_link 初始化为NULL。这本身并不是一个错误,但从更大的角度来看,它会产生这样的效果,即当上下文的 start 函数返回时,运行它的(OS)线程将退出。据推测,您更愿意有机会在不同的环境中进行交换。

  • 您使用setcontext() 切换到t1 上下文。如果成功,此调用不会返回,无论是当时还是以后,您都无法稍后切换到 t2 上下文。但实际上,当 t1 的 start 函数返回时,线程以及整个程序都会退出(见上文),所以它对你来说没有实际意义。不过,就其价值而言,您可能应该改用swapcontext()

  • thread_create() 被声明为返回 int,但它没有 return 语句。

gcc 应该对其中一些问题发出警告,顺便说一句。如果不是,则调高警告级别。 -Wall 级别应该足够了,但我也经常打开 -Wextra 以查找问题。偶尔会有一些警告您可以放心地忽略(尤其是-Wextra),但您应该对每一个单独进行评估。

【讨论】:

  • 我已经更新了我的问题。 NULL thread-&gt;thread_context.uc_linksetcontext() 旨在最小化程序。不过,感谢您的建议。
【解决方案2】:

我认为,你把“thread.h”,你为什么要使用线程 如果你可以试试

【讨论】:

  • 这不是问题的答案。此外,它没有帮助。 ucontext.hgetcontext() 和 OP 试图用来实现用户空间线程的相关函数的正确头文件(根据 POSIX)。
猜你喜欢
  • 2015-11-03
  • 1970-01-01
  • 2011-11-13
  • 2013-01-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多