【问题标题】:crash at __kernel_vsyscall() doesn't occur after GCC optimization disabled禁用 GCC 优化后不会发生 __kernel_vsyscall() 崩溃
【发布时间】:2011-05-25 05:32:01
【问题描述】:

我的应用程序发生了严重的崩溃。 GDB 总是回溯到__kernel_vsyscall()。调试后在源代码中没有发现任何可疑之处。

但在 GCC 编译器中随机禁用一次“-O3”优化标志似乎可以解决问题。我不确定这是否是崩溃的原因,或者编译器是否在优化过程中做了一些讨厌的事情。任何评论或信息都会有所帮助。

在下面显示的一些回溯中,在应用程序代码中观察到的唯一错误是从 MsgQ (buffLen) 接收到的缓冲区的长度。但源代码确保通过 MsgQ 发送和接收的消息的最大大小为 2048 字节。无法追踪 msgrcv() 调用返回的长度为何以及何时损坏。

崩溃 1:

  1. 0x00110416 in __kernel_vsyscall()
  2. 0x00352391 in send() from /lib/libc.so.6
  3. /lib/libc.so.6 中的 __vsyslog_chk () 中的 0x0034d31c
  4. 0x0034d5b7 in syslog () from /lib/libc.so.6
  5. procType1Msg 中的 0x0804f08f(MsgBuff=0xbfc10275)
  6. procRcvdMsQBuf 中的 0x080498c5(buffLen=134515184,buff='值优化出来')
  7. 主要(argc=3,argv=0xbfc10b24)

崩溃 2:

  1. 0x00110416 in __kernel_vsyscall()
  2. 0x00352391 in send() from /lib/libc.so.6
  3. /lib/libc.so.6 中的 __vsyslog_chk () 中的 0x0034d31c
  4. 0x0034d5b7 in syslog () from /lib/libc.so.6
  5. dumpMsg 中的 0x0806234b (buff=0xbfe01832 "U\006\" x,¨n,#®U\027\bI@\024",len=23)
  6. procType1Msg 中的 0x0804e539(MsgBuff=0xbfe01815)
  7. procRcvdMsQBuf 中的 0x0804956d(buffLen=134515040,buff='值优化出来')
  8. main (argc=3, argv=0xbfe020c4)

崩溃 3:

  1. 0x00110416 in __kernel_vsyscall()
  2. 0x00353e3f in msgrcv () from /lib/libc.so.6
  3. getMsgQBuffer 中的 0x080639b9(msg_id=196611, pMsg=0xbfa9d360, lMsgType=0, piErrorNo=0xbfa9d35c)
  4. 0x080497dd in main(argc=无法访问地址 0x30003 处的内存)

【问题讨论】:

  • 使用-O2会发生什么?

标签: linux gcc system-calls


【解决方案1】:

我的猜测是您的代码中某处存在内存损坏(可能是缓冲区溢出)。

当您使用 3 级优化进行编译时,编译器输出的代码使得缓冲区溢出会覆盖一些重要的东西(可能会破坏堆栈?),而且编译器在没有优化的情况下运行时生成的非优化代码也是如此标志是不同的,因此溢出会覆盖其他东西并且不会导致这种特定症状。该错误可能仍然存在,它可能会以其他方式表现出来,甚至根本不表现出来 - 直到你更改一些不相关的东西,然后它会再次咬你。

__kernel_vsyscall() 只是一个 glibc 函数,每当您执行系统调用时都会在内部调用它。那里没有什么重要的。

我的建议:在 valgrind 下运行你的程序。它很可能会为您找到内存溢出。

【讨论】:

  • 谢谢 gby... 我也有同样的疑问,但是由于资源限制、代码的详尽性以及它的运行时环境(它是一个 comm.stack),我无法尝试内存检查工具:( 我也觉得内存损坏,如果是这样的话,可能发生在代码中的任何其他地方,而不是必然发生在崩溃点的跟踪路径中。让我找一些时间和技巧来使用内存检查工具,但是它现在看来我的雇主并不担心崩溃,但正如你所说,它仍然存在并且会再次咬人:)
猜你喜欢
  • 1970-01-01
  • 2020-04-02
  • 1970-01-01
  • 2014-10-21
  • 1970-01-01
  • 2012-03-04
  • 2021-06-19
  • 2014-09-08
  • 2018-12-11
相关资源
最近更新 更多